Kaspersky Lab is committed to providing great support to our customers. Our core team of architects, software developers, and test and support engineers not only provides technical support but also develops our products. Our goal is to help our clients design, build and develop the best solutions on the market.
Support is available through a dedicated online portal, one-to-one helplines, community portal, FAQs and more. Please refer to the contract for support T&Cs as well as contact details.
There’s nothing revolutionary about creating a secure OS. Other attempts have been made to create them and some projects even succeeded. However, the cost of implementation was astronomical and they have only ever been used in airplanes. Until now, no one has succeeded in creating a solution that can be widely adopted beyond highly specialized niche areas.
Most other projects were limited to the realm of academic research. Some bright minds would build a microkernel, validate the solution’s security model, publish the results and celebrate it with champagne and speeches. And that would be the end of it. No project has ever reached full-scale deployment or seen widespread commercial use.
A car is more than just an engine; it can’t function without wheels, suspension, brakes and lots of other important things. The same is true for a secure OS – a microkernel alone is not enough, even if it boasts exceptional characteristics. You also need drivers, services, applications, practical development tools, a developer community. In the absence of a fully-fledged infrastructure, all your work, no matter how advanced and wonderful it may be, is only going to attract a few enthusiasts or geeks.
Another problem is that security is never an abstract concept. The security of a database server, the security of an industrial controller and the security of an IoT solution are three different kinds of security. However, all existing secure operating systems, with the exception of KasperskyOS, are built around a single security model, for example, object capability, which means they don’t have the necessary characteristics in every case.
For KasperskyOS we created (adapted from open source or developed from scratch) a lot of components ready for use ‘out of the box’. In addition, with KasperskyOS it’s possible to ensure a highly granular and flexible configuration of the exact security properties required in different spheres, depending on the specifics of the application.
We created three products: an operating system (KOS), a standalone secure hypervisor (KSH), and a dedicated system for secure interaction (KSS) that calculates verdicts on whether an action can proceed or not, based on defined security policies.
These components can be used independently or in combination, making it possible to solve functional tasks without compromising on security.
Everything can be hacked. The whole point of cybersecurity is to make the lives of cybercriminals as difficult as possible and cyberattacks so costly that they become unprofitable. In this respect, our OS is way ahead of any competition. Moreover, if one of the OS components is hacked, it can’t influence the functioning of the other system components. In a properly constructed system any anomalous behavior by the component will be promptly detected and its proper functioning will be restored.
KasperskyOS provides a wide range of tools to make solutions secure. However, it is only possible to build a secure solution by using those tools correctly. Security is a complex issue. Kaspersky Lab experts have devised a methodology that describes the practical steps required to build secure-by-design solutions based on KasperskyOS, including:
Only secure-by-design solutions can be considered to be secure.
The microkernel does not gather or transmit anything – that can be easily checked by looking at the source code. The microkernel itself has almost nothing in it. All the drivers, system services, applications, etc. are kept outside the microkernel and are isolated.
Their behavior is restricted by security policies. Even if one of the system components tries to save something and send it somewhere, it cannot do so unless it is explicitly specified in the security policy for that specific solution.
All the security policies are defined at a single point independently of functional logic. They are set in high-level language, which makes it easy to audit them. If it is not defined in the security policies, no component can send data, not matter how hard it tries.
KasperskyOS is a special-purpose operating system, and like any other embedded OS it can be fine-tuned for a variety of purposes. The cost of a redistribution license for a solution based on KasperskyOS varies greatly, depending on the type of project, the level of involvement by Kaspersky Lab experts, the customer’s business model, the expected shipping volumes and price of the devices involved.
We have developed special sets of methodology recommendations and special SDKs for the telecom and automotive industries as well as for industrial infrastructure that speed up the development of projects and reduce costs for the customer. The package of commercial documents for KasperskyOS include a redistribution license, developer license (price depends on the number of work places) and technical support license (price depends on terms, conditions and volume of shipped devices).
KasperskyOS is a special-purpose operating system. It is possible to integrate it with existing applications, in order to maintain our security principles, these have to be significantly reworked.
At the moment, implementation of the strict, efficient security model offered by KasperskyOS is only possible for specialized hardware and applications that provide broad but finite functionality. Its secure implementation is only possible when taking into account all the details (software architecture, hardware capabilities, etc.).
We provide technical support to our customers according to the terms set out in the contract. We only provide technical support for the evaluation version – KasperskyOS Starter Kit – at the technical documentation level and via our forum.
No. KasperskyOS is a completely original operating system, developed from scratch.
KasperskyOS currently supports x86, x86_64, ARMv5, ARMv7, ARMv8 and MIPS32 architectures. The KasperskyOS architecture means it is easy to port the solution to new hardware platforms. A necessary condition is the availability of a Memory Management Unit (MMU) and it’s highly recommended to have some means of access control when using DMA (IOMMU, SDMA, etc.). Kaspersky Lab is working on support for platforms typically used in various industries such as telecommunications or the industrial sector. There is additional hardware support within the framework of specific projects based on customer requirements.
KasperskyOS microkernel is written in C (C99 standard).
For applications we support the POSIX compatibility level to ensure full compatibility with profiles PSE51, PSE52 and POSIX 1003.13. POSIX 1003.1 is partly supported (for example, primitives for process control such as fork, exec and some others are not supported). POSIX is not fully supported because potential security threats can arise when using such functions.
Applications can be written in C as well as in other languages, for example in C++. At the moment we are working on the adoption of Java Runtime Environment. There are examples of script languages such as Lua being successfully used.
A peculiarity of the created applications is that, in addition to functional logic, an interface specification is required. There also needs to be a description of the overall architecture – how it is divided into components and security domains and a description of the corresponding security policies. This can be done using a set of specific programming languages developed by Kaspersky Lab experts.
The easiest way to boot an image to a device is to use off-the-shelf loaders such as GRUB or U-Boot. For this purpose an executable image can be built in ELF format (with multiboot support). Designated loaders can also be used to ensure secure boot (measured boot, verified boot).
In the future we plan to make UEFI the main boot option. The current boot options will also be supported.
KasperskyOS supports SMP on x86 (32/64) architectures as well as on ARM. The main primitive for synchronization in the user space is Futex. All other primitives such as Mutex, Semaphore, conditional variables, events, etc. are based on this. For work with primitives you can use your own API provided by KasperskyOS as well as POSIX API.
KasperskyOS provides a level of POSIX compatibility for all components (not including the microkernel) with some exceptions. PSE51 and PSE52 POSIX 1003.13 profiles are fully supported. POSIX 1003.1 is also supported with the exception of several primitives for process control (such as fork() and exec()). The exclusions are due to potential violations of the isolation between solution components when using a range of POSIX functions (for example fork) and this cannot be controlled.
As a standard library for C language, KasperskyOS uses an adapted version of a libc implementation from NetBSD.
At the system level there is currently support for VESA-compatible video cards in framebuffer mode. In addition, we have developed our own proper video drivers for several popular SoCs. At the application level, we provide QT library version 5.10 with Wayland support and adapted for KasperskyOS.
We haven’t implemented kexec to boot a Linux kernel because it contradicts the principles of KasperskyOS. As part of our approach, you can run Linux (or another third-party operating system) using virtualization. Kaspersky Lab has a hypervisor (Kaspersky Secure Hypervisor, KSH) that allows you to run a third-party operating system on top of KasperskyOS, while retaining the ability to control the behavior of the third-party operating system using KasperskyOS functionality (you can control access to equipment, control data, etc.). For instance, this is how Astra Linux can be run using a hypervisor on top of KasperskyOS.
Yes, there is support. We use GCC 4.9.3 with binutils 2.26 and our standard C library conforms to C99 standard (though not yet certified). We also have a POSIX1-2008 compatibility layer. This layer conforms to POSIX1-2008 in terms of system interface. We do not provide the system utilities described in this standard. And we do not implement, or at least we implement differently, some of the POSIX functions (e.g. the fork() family of functions). Also, we do not prohibit the use of any GCC extensions provided by our toolchain.
It does. Our standard C library uses VFS as a backend to perform I/O operations (i.e. socket/file I/O). The basic version of VFS is shipped with two types of file system: FAT32 and RAMFS. We also support ext2/3/4, jffs2 and romfs (init ram disk).
You can easily add your own file system to our VFS layer (there is an example in our SDK on how to use ext2/3/4 file systems by porting a third-party library ‘Lightweight ext4 filesystem library’). Also, our VFS layer can be used in several ways:
Our product is supplied as KasperskyOS SDK. It contains a microkernel, toolchain, ready-for-use components (libraries, services), examples, documentation and all other necessary parts.
Developers can build the product they want from these components, describe the security policies and get the solution they need.
It depends entirely on the answer to the previous question. As a rule, all scenarios should be supported.
Does any scenario require write access?
It depends, but in general, yes.
With regards to RO support for a single file system, what should be implemented first?
It doesn’t matter which file system is implemented first. But for simplicity we would suggest starting with support for exFAT.
RW support for a single file system or RO support for multiple file systems?
It’s better to have a single file system with RW support.
What about RW support for multiple file systems?
As mentioned above, the file system that is implemented depends on the requirements of our customers.
We have a special product called KasperskyOS Starter Kit that is designed to demonstrate the principles of KasperskyOS operation as well as the ability to work with various security policies of Kaspersky Security System. Starter Kit includes examples of applications with various security policies. Starter Kit functions as a virtual machine for QEMU.
As a debugger we suggest GNU GDB. Debugging is performed in the standard way for embedded systems:
In addition, we want to switch to the 6th (and possibly the 7th) version of GCC by default by the end of 2018.