The API is defined in the header file sysroot-*-kos/include/kos/task.h from the KasperskyOS SDK.
The API lets you create, start, and terminate processes, and statically create IPC channels and transfer handles.
Information about API functions is provided in the table below.
The libkos library also provides a low-level API for process management. The low-level API should be used only if the high-level API does not have sufficient capabilities.
Creating a process
To create a process, call one of the following functions:
KosTaskCreate()KosTaskInitEx()KosTaskInit()KosTaskInitFromSegEx()KosTaskInitFromSeg()KosTaskLaunch()With the exception of KosTaskCreate(), these functions receive the parameters of the created process via the input parameter params. This same input parameter is available in the KosTaskSetup() function, which lets you define the parameters of a process that was created by calling the KosTaskCreate() function. Use the params parameter to pass the structure containing the following fields:
eiid – pointer to the process class name.endpointsCount – number of provided endpoints.The field can have a zero value if the process does not provide endpoints.
endpoints – pointer to the array of structures containing the characteristics of provided endpoints (names and RIIDs of endpoints, names of interfaces).The type of structure is defined in the header file sysroot-*-kos/include/services/handle/if_connection.h from the KasperskyOS SDK.
The field can have the RTL_NULL value if the process does not provide endpoints.
args – pointer to the array of addresses of program startup parameters.The RTL_NULL value must be the last element of the array.
envs – pointer to the array of addresses of program environment variables.Environment variables must have the format <name>=<value>. The RTL_NULL value must be the last element of the array.
flags – flags defining the parameters for creating the process:KOS_TASK_FLAGS_NONE – process creation parameters are absent.KOS_TASK_FLAG_DUMPABLE – the process switches to the "frozen" state as a result of an unhandled exception.For details about the "frozen" state, see Managing processes (low-level API task_api.h).
KOS_TASK_FLAG_CRITICAL – shuts down or restarts the hardware platform as a result of an unhandled exception in a process.The flag may be unavailable for use depending on the specific configuration of the KasperskyOS kernel. If this flag is available, the kernel configuration also defines the optional response to an unhandled exception in a process: shutdown or restart.
You can specify only one of the flags that define the process creation parameters.
componentTree – pointer to the structure containing information from the formal specification of the solution component.The type of structure is defined in the header file sysroot-*-kos/include/nk/types.h from the KasperskyOS SDK. This structure is an element of automatically generated transport code (structure named *_component_tree).
The field may have the value RTL_NULL.
When setting process parameters via the input parameter params of the KosTaskSetup(), KosTaskInit*(), and KosTaskLaunch() functions, you must take into account the following details:
KosTaskSetup() function ignores the eiid and flags fields because the process parameters corresponding to these fields are defined when calling the KosTaskCreate() function via the eiid and flags parameters, respectively.componentTree field has a value other than RTL_NULL, the value in the eiid field will be ignored by the KosTaskInit*() and KosTaskLaunch() functions, and the process class name will be taken from the formal specification of the solution component.componentTree field has a value other than RTL_NULL, the values in the endpointsCount and endpoints fields will be ignored by the KosTaskSetup(), KosTaskInit*(), and KosTaskLaunch() functions, and parameters of the provided endpoints (including the parameters of endpoints of embedded components) will be taken from the formal specification of the solution component.When the KosTaskInit() or KosTaskLaunch() function is called, one of the following values is used as the process name and executable file name:
eiid field, if the value of the componentTree field is equal to RTL_NULL.componentTree field value is different from RTL_NULL.Likewise, these values are applied as the process name and/or executable file path if you call the KosTaskInitEx() or KosTaskInitFromSegEx() function with the RTL_NULL value in the name parameter and/or the path parameter. These values are also applied as the process name if you call the KosTaskInitFromSeg() function with the RTL_NULL value in the name parameter.
The KosTaskCreate() and KosTaskInit*() functions use the outTask output parameter to pass the address of the object describing the child process. This object is a structure that is created in the memory of the parent process and the child process. The developer of a solution does not need to perform operations with the fields of this structure. However, the pointer to this structure must be used as the process ID when calling API functions. A child process can get the address of the object describing it by calling the KosTaskGetSelf() function.
If statically created IPC channels are used to access endpoints provided by a server process, the object describing this server process must be linked to the structures containing information about endpoints from the formal specification of the solution component. This is necessary so that client processes can receive information about endpoints provided by the server process when creating a static IPC channel. To link an object describing a child server process to structures containing information about endpoints from the formal specification of the solution component, this information must be passed through the componentTree field of the params parameter when calling the KosTaskCreate(), KosTaskInit*(), and KosTaskLaunch() functions. A server process that is already running can link the object describing it to structures containing information about endpoints from the formal specification of the solution component by calling the KosTaskSetComponentTree() function. This is required if the running server process does not have a parent process.
When the KosTaskInitEx(), KosTaskInit() or KosTaskLaunch() function is called, the ELF image from the defined executable file in ROMFS is loaded into the memory of the created process. If the ELF image contains the symbol table .symtab and string table .strtab, they are loaded into process memory. Using these tables, the kernel receives the names of functions for generating stack backtrace data (call stack information).
To get information about the ELF image loaded into process memory, call the KosTaskGetElfSegs() function. This function is applicable only to those processes that were created with the specified KOS_TASK_FLAG_DUMPABLE flag. When using this function, the symbol table .symtab and string table .strtab are considered to be loadable ELF image segments along with segments of the LOAD type.
In contrast to the KosTaskInit*() and KosTaskLaunch() functions, the KosTaskCreate() function creates an "empty" process, which is a process in whose memory no program ELF image has been loaded. To load ELF image segments into process memory, call the KosTaskLoadSegments() function. To use the KosTaskLoadSegments() function and the KosTaskInitFromSegEx() function, MDL buffers containing loadable ELF image segments must be created in advance. Loadable ELF image segments must be defined via the segs parameter. In addition, the symbol table .symtab and the string table .strtab are also considered to be loadable segments along with segments of the LOAD type. You must use the entry and relocBase parameters to define the program entry point and the ELF image load offset, respectively. The program entry point is the sum of the address specified in the e_entry field of the ELF image header and the ELF image load offset. (For an ELF file of the DYN type, the ELF image load offset must be a random value for ASLR support.) To get the ELF image load offset, you can call the KnTaskVmReserveForElf() function from the task_api.h API, which reserves the virtual memory region for loading the ELF image. If the ELF file has the DYN type, the KnTaskVmReserveForElf() function uses the relocBase output parameter to pass a random offset, and it passes a zero offset for an ELF file of a different type. (The KosTaskInitEx(), KosTaskInit(), and KosTaskLaunch() functions also set a random offset for an ELF file of the DYN type and a zero offset for an ELF file of a different type.) Data passed to the KosTaskLoadSegments() and KosTaskInitFromSegEx() functions with the count, segs, and entry parameters, and parameters related to loading the symbol table .symtab and the string table .strtab are prepared by the KnElfCreateVmSegEx() function from the elf_api.h API.
The KosTaskInitFromSeg() function is a simplified version of the KosTaskInitFromSegEx() function and does not let you load the symbol table .symtab, string table .strtab into process memory, and does not let you define the ELF image load offset (instead, it sets a null offset).
The KosTaskLaunch() function creates and immediately starts a process without the capability to statically create IPC channels.
The KosTaskSetArgs() and KosTaskSetEnv() functions define the program startup parameters and environment variables, respectively. These functions are intended for use by the libkos library.
The KosTaskAddEndpoints() function registers the endpoints provided by the process. This function is intended for use by the libkos library.
Statically created IPC channels
Before starting processes, you can create IPC channels between them. You can create multiple IPC channels with different names between one client process and one server process. You can create IPC channels with the same name between one server process and multiple client processes.
To create an IPC channel with a name matching the name of a server process class, call the KosTaskConnect() function.
To create an IPC channel with a defined name, call the KosTaskConnectToService() function.
To use the created IPC channel, you must get the IPC handle on the client side and on the server process side by calling the SLStaticResolveHandle() function from the API sl-static.h. This function uses the channelName parameter to receive the name of the IPC channel.
Transferring handles to a child process
A parent process can transfer handles to a child process that is not yet running. (General information about transferring handles is provided in the Transferring handles section.)
To pass a handle to a child process, call the KosTaskTransferResource() function while specifying the handle of the resource transfer context object, the permissions mask, and the conditional name of the descendant of the transferred handle in addition to the other parameters.
To find the descendant of a handle transferred by a parent process, call the KosTaskLookupResource() function from the child process while specifying the conditional name of the descendant of the handle that was defined by the parent process when calling the KosTaskTransferResource() function.
Starting a process
To create and immediately start a process without statically creating IPC channels, call the KosTaskLaunch() function.
To start an already created process for which you can create the necessary IPC channels before starting this process, call the KosTaskRunEx() or KosTaskRun() function.
Use the fsBackend parameter of the KosTaskRunEx() function to specify whether to use the kernel or the system program FSUsr to support the ROMFS file system for the started process by default (for details, see Using the ROMFS file system (low-level API fs_api.h)). In a process started by a call of the KosTaskRun() or KosTaskLaunch() function, the default support of the ROMFS file system is the same as the default support for the parent process when the KosTaskRun() or KosTaskLaunch() is called. To get information about how the ROMFS file system is supported for a process, call the KosTaskGetSelfFSBackend() function from this process. (The KosTaskSetSelfFSBackend() function writes information regarding how the ROMFS file system is supported for the calling process to the object describing the process. This function is intended for use by the libkos library.)
The parent process can put the ROMFS file system in the user space and mount it so that it can then be used by the child process by default. To do so, the parent process calls the KnFsChangeBackend() function from the fs_api.h API to indicate that the ROMFS file system for the process is supported by the FSUsr program, and it calls the KnFsChange() function from the fs_api.h API to mount the required ROMFS image. Then the parent process starts the child process by calling the KosTaskRun(), KosTaskRunEx() or KosTaskLaunch() function. (When calling the KosTaskRunEx() function, you must explicitly specify that the ROMFS file system for the child process will be supported by the FSUsr program.) As a result, by default the child process will use the ROMFS file system that is put into the user space by the parent process.
If the parent process does not need to terminate the child process or wait for its termination, the object describing the child process must be deleted and the reference counter for it must be reset by using the KosTaskPut() function after the child process is started. The KosTaskLaunch() function calls the KosTaskPut() function after the child process is started.
Terminating a process
The API terminates and waits for termination of child processes.
To terminate a child process, call the KosTaskStop() or KosTaskStopAndWait() function.
To wait for a child process to terminate on its own initiative, call the KosTaskWait() function.
To ensure that the kernel object describing a child process is deleted after this process is terminated, its handle in the parent process must be closed before or after termination of the child process. The handle of the child process is closed when the object describing the child process is deleted from the memory of the parent process. To delete an object describing a child process, reset the reference counter for this object by using the KosTaskPut() function. The KosTaskLaunch() function calls the KosTaskPut() function after the child process is started.
For details about terminating processes, see Managing processes (low-level API task_api.h).
Getting a process handle
To get the handle of a process, call the KosTaskGetHandle() function.
The handle of a process can be transferred to another process via IPC.
The handle of a calling process that was received by calling the KosTaskGetHandle() function cannot be closed. If closed, this handle may be used to identify other resources, which will lead to errors. Descendants of this handle can be closed without a risk of similar errors occurring.
Getting the startup parameters and environment variables of a program
The KosTaskGetArgsList() function lets you get the startup parameters of a program. The KosTaskFreeArgsList() function lets you delete the array of addresses of program startup parameters that were obtained by calling the KosTaskGetArgsList() function.
The KosTaskGetEnvList() function lets you get the environment variables of a program. The KosTaskFreeEnvList() function lets you delete the array of addresses of program environment variables that were obtained by calling the KosTaskGetEnvList() function.
All these functions are intended for use by the libc library.
Information about API functions
task.h functions
Function |
Information about the function |
|---|---|
|
Purpose Creates a process. Parameters
Returned values If successful, the function returns |
|
Purpose Sets the parameters of a process. Parameters
Returned values If successful, the function returns |
|
Purpose Loads ELF image segments into process memory. Parameters
Returned values If successful, the function returns |
|
Purpose Creates a process. Parameters
Returned values If successful, the function returns |
|
Purpose Creates a process. Parameters
Returned values If successful, the function returns |
|
Purpose Creates a process. Parameters
Returned values If successful, the function returns |
|
Purpose Creates a process. Parameters
Returned values If successful, the function returns |
|
Purpose Gets information about the ELF image loaded in process memory. Parameters
Returned values If successful, the function returns |
|
Purpose Creates an IPC channel. Parameters
Returned values If successful, the function returns |
|
Purpose Creates an IPC channel with the defined name. Parameters
Returned values If successful, the function returns |
|
Purpose Defines the program startup parameters. Parameters
Returned values If successful, the function returns |
|
Purpose Gets the program startup parameters. Parameters
Returned values If successful, the function returns |
|
Purpose Deletes the array of addresses of program startup parameters that was received by calling the Parameters
Returned values N/A |
|
Purpose Defines environment variables of a program. Parameters
Returned values If successful, the function returns |
|
Purpose Gets the environment variables of a program. Parameters
Returned values If successful, the function returns |
|
Purpose Deletes the array of program environment variable addresses that was received by calling the Parameters
Returned values N/A |
|
Purpose Resumes a process. Parameters
Returned values If successful, the function returns |
|
Purpose Resumes a process. Parameters
Returned values If successful, the function returns |
|
Purpose Terminates a process. Parameters
Returned values If successful, the function returns |
|
Purpose Terminates a process and waits for the termination of this process. Parameters
Returned values If successful, the function returns Additional information Non-blocking call if the |
|
Purpose Waits for the termination of a process. Parameters
Returned values If successful, the function returns Additional information Non-blocking call if the |
|
Purpose Gets the process handle. Parameters
Returned values Process handle. |
|
Purpose Creates and starts a process. Parameters
Returned values If successful, the function returns |
|
Purpose Gets the address of an object that describes a calling process. Parameters N/A Returned values Pointer to the object describing the process, or Additional information The function adds 1 to the reference counter for the object describing the process, therefore the |
|
Purpose Subtracts 1 from the reference counter for the object describing the process. Parameters
Returned values N/A |
|
Purpose Registers endpoints. Parameters
Returned values If successful, the function returns |
|
Purpose Writes information about how ROMFS file system support is provided for the calling process (by the kernel or by the Parameters
Returned values N/A |
|
Purpose Gets information indicating whether the ROMFS file system for a calling process is supported by the kernel or by the system program Parameters N/A Returned values Value indicating whether the ROMFS file system is supported by the kernel or by the system program |
|
Purpose Creates structures containing information about endpoints from the formal specification of the solution component and links these structures to the object describing the process. Parameters
Returned values If successful, the function returns |
|
Purpose Transfers a handle to a process that is not yet running. Parameters
Returned values If successful, the function returns |
|
Purpose Searches for a handle based on the name defined by the Parameters
Returned values If successful, it returns the handle. Otherwise, it returns |