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.
Well, we don’t claim to have created something completely new. Of course there have been other attempts to create a secure OS. At times some projects even succeeded, but the cost of their implementation is on a par with that of an airplane (curiously, such systems were indeed used on airplanes), so such projects were never destined to produce widely applied kit.
Other projects were mostly limited to the realm of academic research. In other words, some bright minds would build a microkernel and celebrate with champagne and speeches, and that would basically be it. No project has ever reached the stage of full-scale deployment or commercialization. But a functional vehicle does not end with an engine; it can’t function without wheels, suspension and myriad other important stuff.
We decided to design the system so as to be relevant in different spheres, allowing customization on a granular level, based on application. Basically, we created three products. They are: an OS (KOS), a standalone secure hypervisor (KSH), and a dedicated system for secure interaction among OS components (KSS). They can address various challenges on their own too, depending on the application.
Yes, that is true. Anything can happen. However, that’s no reason to give up! The very essence of cybersecurity is to make cybercrooks’ lives as difficult as possible, and make cyberattacks so costly that they become unprofitable business. In this respect, our OS is ahead of any competition.
The kernel does not transmit anything anywhere — that can be easily checked by looking at the source code. The microkernel has practically nothing in it. All drivers are kept isolated. So to pass any data, one has to write another piece of code. It will be seen quite clearly — you don’t even have to look at the source code to see it. All of this is written in security policies. And the customer will always be able to audit those policies, regardless of the code. If the policies contain no instructions to send data, the system doesn’t do it.
KasperskyOS is a special-purpose operating system, but like any other embedded OS it can be fine-tuned for a variety of purposes. The amount of work required to develop a device or application based on KasperskyOS varies greatly, depending on the type of project and the level of involvement of Kaspersky Lab’s experts. We have developed special packages for the telecom and automotive industries as well as industrial infrastructure that speed up the development of projects and reduce costs for the customer. Therefore, the price of KasperskyOS depends on the complexity of the project as well as the number of devices produced.
KasperskyOS is a special-purpose operating system. Although it is possible to integrate it with existing applications, in order to maintain our security principles, these have to be significantly reworked. This requires efforts way beyond the capabilities of Kaspersky Lab’s R&D or any other software vendor. At the moment, implementing the strict, efficient security model offered by KasperskyOS is only possible with specialized hardware and applications.
KasperskyOS currently supports x86, x64 and ARM architectures. Kaspersky Lab is working on support for platforms typically used in specific industries such as telecommunications or the industrial sector. There is additional support of hardware as part of specific projects, based on customer requirements.
We provide technical support to our customers according to the terms of contract. We do not plan to provide technical support for the upcoming publicly available evaluation version of KasperskyOS.
Most of the OS is written in C and C++. As for existing applications, we support standard programming languages, but the method of programming differs slightly from the conventional method.
On x86 architecture, the KasperskyOS image is loaded via the GRUB bootloader. The bootable image format for x86 is ELF with a multiboot specification.
On ARM architecture, KOS is loaded using the U-Boot bootloader. The format of the bootloader image is ELF.
In future, we plan to make UEFI the main bootable option. The current boot options will also be supported.
KasperskyOS supports SMP on x86 architecture as well as on iMX6 ARM CPU. The kernel provides for a Futex user space implementation. All other synchronization in the user space is based on this. Event, Mutex, Semaphore are supported in native and POSIX API libraries.
We wanted to make our API POSIX compliant, but it is not always possible. The problem is that the KOS ideology is based on a component model, and interaction between the components are strongly typed; all the IPC calls go through the KOS kernel and are controlled by a single system – KSS (Kaspersky Security System). This is good in terms of security, but it means it’s impossible to implement a fork, for example.
Our developers strive to conform as closely as possible with Posix, and Posix compatibility with API is now supported in a significant number of cases.
Identifying unsupported features is quite difficult. It would require a lot of time and effort because the POSIX specification is very broad. If you could specify what you want, we could then give a more definitive answer.
With regards to libc, KasperskyOS uses the standard library newlib version 2.0.0.
Framebuffer is supported by KasperskyOS.
KasperskyOS supports the VESA video card for x86. It also supports graphical output for the ARM Freescale IMX6 processor. With regards to high level graphics libraries, there is support for Qt 5.7 and QML, based on Framebuffer.
We haven’t performed a Linux kexec 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 we ran Astra Linux using a hypervisor on top of KasperskyOS.
It does. 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 by this standard. And we do not implement, or at least 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 shipped with two types of file systems: FAT32 and RAMFS. But you can easily add your own file system into 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:
Basically, it depends on the requirements of our customers. But we would suggest paying attention to file systems for embedded solutions (e.g. JFFS2, UBIFS etc.).
It depends entirely on the answer to the previous question. As a rule, all scenarios should be supported.
Does any scenario require write access?
Again, it depends. But in general, yes.
Single file system RO support and which FS must be implemented initially?
It doesn’t matter what file system is implemented first. But for simplicity we would suggest exFAT.
Single file system RW support or multiple file systems RO support?
It would be better to have a single file system with RW support.
Finally, what about multiple file systems RW support?
As we mentioned above, the file system that is implemented depends on the requirements of our customers.
Yes, we can provide one of the latest versions of our SDK, but only after a formal release.
We deliver cross-toolchain based on the GNU Compiler Collection (GNU Compiler Collection, version 4.9 – basic, 5.4 and 6.2 – support in test mode). If necessary, Clang / LLVM compiler can be included in the product.
As a debugger we use GNU GDB. Debugging is performed in the standard way for cross-toolchain: