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.

    ...

    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.

    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})

Page top