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:
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
.CMakeLists.txt
files.README.md
files. These files have the same type of contents and refer to this Guide.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 |
Yes |
Yes |
Yes |
echo |
Demonstrates interaction between programs via IPC. The |
Yes |
Yes |
Yes |
ping |
Demonstrates use of a solution security policy to control IPC interaction between programs. The two interface methods |
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 |
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 |
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 |
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 |
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 |
Yes |
Yes |
Yes |
vfs_extfs |
Demonstrates how to mount block device file systems (ext2, ext3, ext4). The |
Yes |
Yes |
Yes |
multi_vfs_ntpd |
Demonstrates support of the Network Time Protocol (NTP). The |
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 |
Yes |
Yes |
Yes |
multi_vfs_dhcpcd |
Demonstrates support of the network protocol named Dynamic Host Configuration Protocol (DHCP) in KasperskyOS. The |
Yes |
Yes |
Yes |
mqtt_publisher |
Demonstrates support of the Message Queue Telemetry Transport (MQTT) protocol for exchanging messages in KasperskyOS. The |
Yes |
Yes |
Yes |
mqtt_subscriber |
Demonstrates support of the Message Queue Telemetry Transport (MQTT) protocol for exchanging messages in KasperskyOS. The |
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 |
No |
Yes |
Yes |
gpio_output |
Demonstrates use of the GPIO driver for output via GPIO pins. The |
No |
Yes |
Yes |
gpio_interrupt |
Demonstrates use of the GPIO driver to verify the operation of interrupts for GPIO pins. The |
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 |
No |
Yes |
Yes |
i2c_ds1307_rtc |
Demonstrates use of the Inter-Integrated Circuit (I2C) driver on the Raspberry Pi 4 B hardware platform. The |
No |
Yes |
No |
i2c_bm8563_rtc
|
Demonstrates use of the Inter-Integrated Circuit (I2C) driver on the Radxa ROCK 3A hardware platform. The |
No |
No |
Yes |
uart |
Demonstrates use of the Universal Asynchronous Receiver-Transmitter (UART) driver. The |
Yes |
Yes |
Yes |
spi_check_regs |
Demonstrates use of the Serial Peripheral Interface (SPI) driver. The |
No |
Yes |
Yes |
barcode_scanner |
Demonstrates use of a Universal Serial Bus (USB) driver via the |
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 |
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 |
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 |
No |
No |
Yes |
adc_hello |
Demonstrates use of the Sensors driver to check the ADC functionality on the Radxa ROCK 3A hardware platform. The |
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 |
Yes |
Yes |
Yes |
koslogger |
Demonstrates use of the |
Yes |
Yes |
Yes |
pcre |
Demonstrates use of the |
Yes |
Yes |
Yes |
iperf_separate_vfs |
Demonstrates use of the |
Yes |
Yes |
Yes |
messagebus |
Demonstrates use of the |
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 |
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: |
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 |
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 |
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 |
Yes |
Yes |
Yes |