KasperskyOS Community Edition 1.3

Examples in KasperskyOS Community Edition

In addition to the Developer's Guide, the KasperskyOS Community Edition SDK provides examples of KasperskyOS-based solutions. The examples are located in the directory /opt/KasperskyOS-Community-Edition-<version>/examples. Each example resides in a separate directory containing the following:

  • Directories containing the source code of programs.
  • The resources directory contains the formal specification of the solution component. This directory may optionally contain files necessary for the example to work. For example, it may contain the network configuration files hosts, dhcpcd.conf and ntp.conf.
  • Solution build scenarios in the form of CMakeLists.txt files.
  • README.md files. These files have the same type of contents and refer to this Guide.
  • [Optional] The vendor directory contains the libraries and their metadata required for managing dependencies in Rust-based projects.

Before running the examples on Radxa ROCK 3A, you also need to build the drivers provided as a source code in the SDK. Instructions for building drivers can be found in the descriptions of examples (README.md files).

The table below provides a description of examples for developing basic solutions.

Basic solutions

Example directory in the SDK

Brief description of the example

Running in QEMU

Running in Raspberry Pi 4 B

Running on Radxa ROCK 3A

hello

Demonstrates the most basic solution. The Hello program sends a message to standard error. For more details, refer to hello example.

Yes

Yes

Yes

echo

Demonstrates interaction between programs via IPC. The Client sends data to the Server program, receives the modified data in return, and prints that data to standard error. For more details, refer to echo example.

Yes

Yes

Yes

ping

Demonstrates use of a solution security policy to control IPC interaction between programs. The two interface methods Ping and Pong provided by the Server program are called by the Client program in a varying sequence. However, the solution security policy allows only alternating calls of Ping and Pong. For more details, refer to ping example.

Yes

Yes

Yes

hello_from_rust

Demonstrates how to let your solution include a simple program that was developed based on Rust and built using the Cargo build system and package manager. The Hello program sends a message to standard error. For more details, refer to hello_from_rust example.

Yes

Yes

Yes

hello_corrosion

Demonstrates how to let your solution include a simple program that was developed based on Rust and uses Corrosion, which is a set of libraries for integrating Rust into CMake projects. The Hello program sends a message to standard error. For more details, refer to hello_corrosion example.

Yes

Yes

Yes

The table below provides a description of examples that demonstrate the use of file systems and a network stack.

Using file systems and a network stack in solutions

Example directory in the SDK

Brief description of the example

Running in QEMU

Running in Raspberry Pi 4 B

Running on Radxa ROCK 3A

embedded_vfs

Demonstrates how to include a system program that implements file systems and a network stack in a solution. The Client program creates a directory, creates and deletes a file, and reads from a file or writes to a file. For more details, refer to embedded_vfs example.

Yes

Yes

Yes

net_with_separate_vfs

Demonstrates how to establish a connection between programs running in KasperskyOS via TCP sockets using a loopback interface. The Client program creates a TCP socket, connects to the server through the loopback interface, sends data to the server, and closes the connection. The Server program accepts the connection request through the TCP socket, receives data from the client, and then closes the connection. For more details, refer to net_with_separate_vfs example.

Yes

Yes

Yes

net2_with_separate_vfs

Demonstrates how to establish a connection via TCP sockets between the client program running in KasperskyOS and the server program running in the host operating system. The Client program creates a TCP socket, connects to the server, sends data to the server, and closes the connection. The Server program accepts the connection request through the TCP socket, receives data from the client, and then closes the connection. For more details, refer to net2_with_separate_vfs example.

Yes

Yes

Yes

vfs_extfs

Demonstrates how to mount block device file systems (ext2, ext3, ext4). The FileVfs program implements the server portion of the virtual file system, thereby providing the interface used for interaction with file systems and block devices. The Client program sends requests to the FileVfs program via IPC to mount file systems to the specified directories and perform basic operations with files (create, write, read, and delete) to verify that the file systems are mounted correctly. For more details, refer to vfs_extfs example.

Yes

Yes

Yes

multi_vfs_ntpd

Demonstrates support of the Network Time Protocol (NTP). The Ntpd program is provided in KasperskyOS Community Edition and is an implementation of an NTP client, which synchronizes the system time with NTP servers. The Client program changes the current system time to the time specified in the macro. After the time is synchronized by the Ntpd program, the year in the received system time is expected to differ from the year that was previously set by the macro. For more details, refer to multi_vfs_ntpd example.

Yes

Yes

Yes

multi_vfs_dns_client

Demonstrates use of the Domain Name System (DNS) for domain name resolution in KasperskyOS. After checking the network connection, the Client program receives information about the DNS server by using its fully qualified domain name and port. Then it resolves the domain name to an IP address and verifies that the IP address matches the previously predefined values. For more details, refer to multi_vfs_dns_client example.

Yes

Yes

Yes

multi_vfs_dhcpcd

Demonstrates support of the network protocol named Dynamic Host Configuration Protocol (DHCP) in KasperskyOS. The Dhcpcd program is provided in KasperskyOS Community Edition and is an implementation of a DHCP client, which configures network interfaces. The Client program receives information about the configured network interfaces and prints them to standard error. For more details, refer to multi_vfs_dhcpcd example.

Yes

Yes

Yes

mqtt_publisher

Demonstrates support of the Message Queue Telemetry Transport (MQTT) protocol for exchanging messages in KasperskyOS. The Publisher program is an implementation of an MQTT publisher running in KasperskyOS that publishes the current time in a loop. The MQTT subscriber running in the host operating system prints messages received from the MQTT publisher to standard output. For more details, refer to mqtt_publisher example.

Yes

Yes

Yes

mqtt_subscriber

Demonstrates support of the Message Queue Telemetry Transport (MQTT) protocol for exchanging messages in KasperskyOS. The Subscriber program is an implementation of an MQTT subscriber running in KasperskyOS that prints messages to standard output when it receives those messages from the MQTT publisher running in the host operating system. For more details, refer to mqtt_subscriber example.

Yes

Yes

Yes

The table below provides a description of examples using the drivers provided in KasperskyOS Community Edition to work with GPIO, I2C, UART, SPI and USB hardware interfaces.

Using drivers in KasperskyOS-based solutions

Example directory in the SDK

Brief description of the example

Running in QEMU

Running in Raspberry Pi 4 B

Running on Radxa ROCK 3A

gpio_input

Demonstrates use of the General-Purpose Input/Output (GPIO) driver for input via GPIO pins. The Client program configures the GPIO pins to output mode and reads their values. For more details, refer to gpio_input example.

No

Yes

Yes

gpio_output

Demonstrates use of the GPIO driver for output via GPIO pins. The Client program configures GPIO pins to output mode and switches them to a logical one (voltage on the pin) and then to a logical zero (no voltage on the pin). For more details, refer to gpio_output example.

No

Yes

Yes

gpio_interrupt

Demonstrates use of the GPIO driver to verify the operation of interrupts for GPIO pins. The Client program configures GPIO pins to input mode and registers interrupt handling functions for all GPIO pins except those specified in the list of exclusions. If an interrupt is triggered on a GPIO pin, the Client program removes the handler function for this GPIO pin. The program terminates when an interrupt occurs on each GPIO pin. For more details, refer to gpio_interrupt example.

No

Yes

Yes

gpio_echo

Demonstrates use of the GPIO driver to verify the input/output functionality of GPIO pins and the operation of interrupts for GPIO pins. The Client program configures two interconnected pins: one pin to input mode and one pin to output mode. It then registers the interrupt handler for the input pin and changes the state of the output pin several times while waiting for the interrupt handler to be triggered. For more details, refer to gpio_echo example.

No

Yes

Yes

i2c_ds1307_rtc

Demonstrates use of the Inter-Integrated Circuit (I2C) driver on the Raspberry Pi 4 B hardware platform. The I2cClient program verifies operation of the real-time clock module on the DS1307Z chip via the I2C driver interface by setting and verifying the date on the device. For more details, refer to i2c_ds1307_rtc example.

No

Yes

No

i2c_bm8563_rtc

 

Demonstrates use of the Inter-Integrated Circuit (I2C) driver on the Radxa ROCK 3A hardware platform. The Bm8653 program verifies operation of the real-time clock on the BM8563 chip via the I2C driver interface by setting and verifying the date on the device. For more details, refer to i2c_bm8563_rtc example.

No

No

Yes

uart

Demonstrates use of the Universal Asynchronous Receiver-Transmitter (UART) driver. The Client program performs the following operations with UART: initialization, opening a port, sending data, and closing a port. For more details, refer to uart example.

Yes

Yes

Yes

spi_check_regs

Demonstrates use of the Serial Peripheral Interface (SPI) driver. The Client program opens an SPI channel, prints its parameters to standard output and sets the required operating mode. The program then uses this SPI channel to forward the data sequence and waits to receive the ID of the ATTiny controller installed on the Sense HAT board. For more details, refer to spi_check_regs example.

No

Yes

Yes

barcode_scanner

Demonstrates use of a Universal Serial Bus (USB) driver via the libevdev library. The BarcodeScanner program uses the libevdev library for interaction with a barcode scanner connected to the USB port of Raspberry Pi 4 B. For more details, refer to barcode_scanner example.

No

Yes

Yes

watchdog_system_reset

Demonstrates use of the Watchdog driver for monitoring the state of KasperskyOS and automatically restarting the Raspberry Pi 4 B. The Client program interacts with the Watchdog timer as follows: changes the default value of the timer to a new value and starts the timer, resets the timer several times, and waits for the operating system to restart when the timer is triggered. For more details, refer to watchdog_system_reset example.

No

Yes

No

mass_storage

Demonstrates use of the UsbMassStorage driver for working with an external USB drive connected to the USB port of the Raspberry Pi 4 B. The FileVfs program implements the server portion of the virtual file system, thereby providing the interface used for interaction with file systems and block devices. The Client program sends requests to the FileVfs program via IPC to mount file systems to the specified directories and perform basic operations with files (create, write, read, and delete) to verify that the file systems are mounted correctly on an external USB drive. For more details, refer to mass_storage example.

No

Yes

Yes

can_loopback

Demonstrates use of the CAN driver on the Radxa ROCK 3A hardware platform when there is no need to connect an additional peripheral device for CAN transceivers. In the example, the CAN port is configured and then a CAN packet is sent. The received CAN packet is checked to make sure that it matches the sent CAN packet. For more details, refer to can_loopback example.

No

No

Yes

can2can

Demonstrates use of the CAN driver on the Radxa ROCK 3A hardware platform to forward a message between two CAN interfaces. In contrast to the can_loopback example, which uses only one CAN interface and does not require additional equipment, this example requires two CAN transceivers that are connected to the CAN_H and CAN_L lines. For more details, refer to can2can example.

No

No

Yes

adc_hello

Demonstrates use of the Sensors driver to check the ADC functionality on the Radxa ROCK 3A hardware platform. The AdcHello program calculates the voltage supplied to the ADC channel, normalizes it and prints it to standard output. For more details, refer to adc_hello example.

No

No

Yes

The table below provides examples of using the libraries provided in KasperskyOS Community Edition to perform various functions, such as logging, applying regular expressions, exchanging messages via IPC, and testing performance.

Using libraries in solutions

Example directory in the SDK

Brief description of the example

Running in QEMU

Running in Raspberry Pi 4 B

Running on Radxa ROCK 3A

shared_libs

Demonstrates the use of dynamic and static libraries in KasperskyOS. The Client program calls functions from a static library, a dynamic library linked together with the program, and a dynamic library loaded into memory when the dlopen() function of the POSIX interface is called. For more details, refer to shared_libs example.

Yes

Yes

Yes

koslogger

Demonstrates use of the spdlog logging library in KasperskyOS via the KOSLogger wrapper library. The Client program writes messages to a log, which is saved on an SD card when an example is started on the Raspberry Pi 4 B or in the sdcard0.img image file when an example is run in QEMU. Messages are written using various log levels. For more details, refer to koslogger example.

Yes

Yes

Yes

pcre

Demonstrates use of the pcre library for working with regular expressions in KasperskyOS. The Client program searches for all occurrences of the necessary word within the defined text fragment and counts the number of these occurrences. For more details, refer to pcre example.

Yes

Yes

Yes

iperf_separate_vfs

Demonstrates use of the iperf library to test network performance. The Server program configures the network interface, then creates and runs a network performance test using the iperf library. For more details, refer to iperf_separate_vfs example.

Yes

Yes

Yes

messagebus

Demonstrates use of the MessageBus component in KasperskyOS. In this example, the Publisher, SubscriberA and SubscriberB programs use the MessageBus component to exchange messages via IPC. For more details, refer to messagebus example.

Yes

Yes

Yes

pal_tests

Demonstrates use of the Policy Assertion Language (PAL) when writing tests for a KasperskyOS-based solution security policy. These tests check the solution security policy prior to starting development of the software code based on the formal specifications of solution components. For more details, refer to pal_tests example.

Yes

Yes

Yes

The table below shows examples of using security patterns in KasperskyOS.

Using security patterns in solutions

Example directory in the SDK

Brief description of the example

Running in QEMU

Running in Raspberry Pi 4 B

Running on Radxa ROCK 3A

secure_logger

Demonstrates use of the Distrustful Decomposition pattern for separating event log read/write operations. The Application program generates a message and forwards it to the Logger program via IPC. The Logger program receives the message and writes it to the event log residing on the drive. The Reader program reads the message from the event log and forwards it to the LogViewer program via IPC. The LogViewer program prints the message to standard output. For more details, refer to secure_logger example.

Yes

Yes

Yes

separate_storage

Demonstrates use of the Distrustful Decomposition pattern to separate data storage for trusted and untrusted programs. The example contains two programs: UserManager and CertificateManager. Each of these programs uses its own instance of the VFS program to access a separate file system. Each VFS program instance includes a block device driver linked to an individual logical drive partition. The UserManager program does not have access to the file system of the CertificateManager program, and vice versa. For more details, refer to separate_storage example.

Yes

Yes

Yes

defer_to_kernel

Demonstrates use of the Defer to Kernel and Policy Decision Point patterns to guarantee isolation of running programs (processes) by the KasperskyOS kernel. In this example, the ValidPictureClient and NonValidPictureClient programs query the PictureManager program to receive information. However, only the ValidPictureClient program is allowed to interact with the PictureManager program. For more details, refer to defer_to_kernel example.

Yes

Yes

Yes

device_access

Demonstrates use of the Privilege Separation pattern in which different programs are responsible for authorization and access to data. The Device program queries the Storage program to receive information and queries the LoginManager program for authorization. The Device program can query the Storage program only after successful authorization in the LoginManager program. For more details, refer to device_access example.

Yes

Yes

Yes

secure_login

Demonstrates use of the Information Obscurity pattern for the capability to transmit critical system information through an untrusted environment. The Civetweb web server interacts with the browser to process authentication requests, and data is transmitted between the browser and the server via the TLS terminator for traffic encryption. The AuthService program generates encryption keys to encrypt passwords based on the Diffie-Hellman algorithm. For more details, refer to secure_login example.

Yes

Yes

Yes