KasperskyOS Community Edition 1.2

Migrating application code from SDK version 1.1.1 to SDK version 1.2

Due to modifications made to SDK components in version 1.2, you must make changes to application code that was developed using KasperskyOS Community Edition version 1.1.1 before using that code with KasperskyOS Community Edition version 1.2.

Required changes:

1. The SDK now includes a driver for working with the VideoCore (VC6) coprocessor via mailbox technology: kl.drivers.Bcm2711MboxArmToVc. The kl.drivers.DNetSrv and kl.drivers.USB drivers require access to this new driver.
   • If the init.yaml.in template is used to create the solution init description (init.yaml file) and the @INIT_ProgramName_ENTITY_CONNECTIONS+@ or @INIT_ProgramName_ENTITY_CONNECTIONS@ macros were used for the kl.drivers.DNetSrv and kl.drivers.USB processes, no changes to the init description are required.

     Otherwise, if IPC channels for the kl.drivers.DNetSrv and kl.drivers.USB processes are manually specified, you must add the kl.drivers.Bcm2711MboxArmToVc process to the init description and define the IPC channels between it and the kl.drivers.DNetSrv and kl.drivers.USB processes:

   - name: kl.drivers.Bcm2711MboxArmToVc path: bcm2711_mbox_arm2vc_h - name: kl.drivers.USB path: usb connections: ... - target: kl.drivers.Bcm2711MboxArmToVc id: kl.drivers.Bcm2711MboxArmToVc - name: kl.drivers.DNetSrv path: dnet_entity connections: ... - target: kl.drivers.Bcm2711MboxArmToVc id: kl.drivers.Bcm2711MboxArmToVc
   • You must add the kl.drivers.Bcm2711MboxArmToVc process to the security.psl file and allow the kl.drivers.DNetSrv and kl.drivers.USB processes and the kernel to interact with it:
   ... use kl.drivers.Bcm2711MboxArmToVc._ ... execute src = Einit dst = kl.drivers.Bcm2711MboxArmToVc { grant () } request src = kl.drivers.Bcm2711MboxArmToVc dst = kl.core.Core { grant () } response src = kl.core.Core dst = kl.drivers.Bcm2711MboxArmToVc { grant () } request src = kl.drivers.DNetSrv dst = kl.drivers.Bcm2711MboxArmToVc { grant () } response src = kl.drivers.Bcm2711MboxArmToVc dst = kl.drivers.DNetSrv { grant () } request src = kl.drivers.USB dst = kl.drivers.Bcm2711MboxArmToVc { grant () } response src = kl.drivers.Bcm2711MboxArmToVc dst = kl.drivers.USB{ grant () }
2. All implementations of the VFS component now require access to the kl.EntropyEntity program.
   • If the init.yaml.in template is used to create the solution init description (init.yaml file) and the @INIT_ProgramName_ENTITY_CONNECTIONS+@ or @INIT_ProgramName_ENTITY_CONNECTIONS@ macros were used for processes that use the VFS component (the kl.VfsNet, kl.VfsRamFs, and kl.VfsSdCardFs processes as well as the processes that statically include VFS), no changes to the init description are required.

     Otherwise, if IPC channels for processes that use the VFS component are manually specified, you must add the kl.EntropyEntity process to the init description and define the IPC channels between it and the processes that use the VFS component:

   - name: kl.VfsSdCardFs path: VfsSdCardFs connections: ... - target: kl.EntropyEntity id: kl.EntropyEntity - name: kl.VfsNet path: VfsNet connections: ... - target: kl.EntropyEntity id: kl.EntropyEntity - name: kl.ProgramWithEmbeddedVfs path: ProgramWithEmbedVfs connections: ... - target: kl.EntropyEntity id: kl.EntropyEntity - name: kl.EntropyEntity path: Entropy
   • You must add the kl.EntropyEntity process to the security.psl file and allow the kernel and processes that use the VFS component to interact with it:
   ... use kl.EntropyEntity._ ... execute src = Einit dst = kl.drivers.EntropyEntity { grant () } ... request src = kl.EntropyEntity dst = kl.core.Core { grant () } response src = kl.core.Core dst = kl.EntropyEntity { grant () } request src = kl.VfsNet dst = kl.EntropyEntity { grant () } response src = kl.EntropyEntity dst = kl.VfsNet { grant () } request src = kl.VfsSdCardFs dst = kl.EntropyEntity { grant () } response src = kl.EntropyEntity dst = kl.VfsSdCardFs { grant () } request src = kl.ProgramWithEmbeddedVfs dst = kl.EntropyEntity { grant () } response src = kl.EntropyEntity dst = kl.ProgramWithEmbeddedVfs { grant () }
3. The kl.drivers.USB driver now requires access to the kl.core.NameServer program.
   • If the init.yaml.in template is used to create the solution init description (init.yaml file) and the @INIT_ProgramName_ENTITY_CONNECTIONS+@ or @INIT_ProgramName_ENTITY_CONNECTIONS@ macros were used for the kl.drivers.USB process, no changes to the init description are required.

     Otherwise, if IPC channels for the kl.drivers.USB process are manually specified, you must add the kl.core.NameServer process to the init description and define the IPC channels between it and the kl.drivers.USB process:

   - name: kl.core.NameServer path: ns - name: kl.drivers.USB path: usb connections: ... - target: kl.core.NameServer id: kl.core.NameServer
   • You must add the kl.core.NameServer process to the security.psl file and allow the kl.drivers.USB process and the kernel to interact with it:
   ... use kl.core.NameServer ... execute src = Einit dst = kl.core.NameServer { grant () } ... request src = kl.core.NameServer dst = kl.core.Core { grant () } response src = kl.core.Core dst = kl.core.NameServer { grant () } request src = kl.drivers.USB dst = kl.core.NameServer { grant () } response src = core.NameServer dst = kl.drivers.USB { grant () }
4. The capability to use dynamic libraries has been added to the SDK. Now all solutions are built using dynamic linking by default. This may affect the build of solutions containing libraries that have both static and dynamic variants.
   • To include enforced static linking of executable files, replace initialize_platform() with initialize_platform (FORCE_STATIC) in the root CMakeLists.txt of the project.
   • To switch from static linking to dynamic linking, you must complete additional steps as described in the article titled Using dynamic libraries.
   • To use dynamic libraries, your solution must include the system program BlobContainer.
   • You must add the kl.bc.BlobContainer process to the security.psl file and allow processes that use dynamic libraries to interact with it:
   ... use kl.bc.BlobContainer ... execute src = Einit dst = kl.bc.BlobContainer { grant () } request { /* Allows tasks with the kl.bc.BlobContainer class to send requests to specified tasks. */ match src = kl.bc.BlobContainer { match dst = kl.core.Core { grant () } match dst = kl.VfsSdCardFs { grant () } } /* Allows task with the kl.bc.BlobContainer class to recive request from any task. */ match dst = kl.bc.BlobContainer { grant () } } response { /* Allows tasks with the kl.bc.BlobContainer class to get responses from specified tasks. */ match dst = kl.bc.BlobContainer { match src = kl.core.Core { grant () } match src = kl.VfsSdCardFs { grant () } } /* Allows task with the kl.bc.BlobContainer class to send response to any task. */ match src = kl.bc.BlobContainer { grant () } }

   You can move the permissions for kl.bc.BlobContainer operations to a separate PSL file and include this file in the solution. (see the secure_logger example in the SDK).

5. The romfs file system can now be mounted only in read-only mode.
   • When mounting romfs in C/C++ code using the mount() function, you must pass the MS_RDONLY flag.
   • You must also make changes to the command-line arguments of the VFS program in the init description or in the CMakeLists.txt file for building the Einit program.

   Example of mounting the romfs file system in the init.yaml file:

   - name: kl.VfsSdCardFs path: VfsSdCardFs connections: - target: kl.drivers.SDCard id: kl.drivers.SDCard - target: kl.EntropyEntity id: kl.EntropyEntity args: - -l - nodev /tmp ramfs 0 - -l - romfs /etc romfs ro env: ROOTFS: mmc0,0 / fat32 0 VFS_FILESYSTEM_BACKEND: server:kl.VfsSdCardFs

   Example of mounting the romfs file system in the CMakeLists.txt file:

   set (VFS_NET_ARGS " - -l - devfs /dev devfs 0 - -l - romfs /etc romfs ro") set_target_properties (${precompiled_vfsVfsNet} PROPERTIES EXTRA_ARGS ${VFS_NET_ARGS})