Appendices > Examples in KasperskyOS Community Edition
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
|
Article ID: additional_examples, Last review: Feb 20, 2025