Frequently Asked Questions

  1. A secure OS is not news! So what?

    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.

  2. Everything can be hacked, and your OS is no exception!

    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.

  3. Will KasperskyOS collect data?

    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.

  4. How much does KasperskyOS cost?

    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.

  5. Do you plan to transform KasperskyOS into a general-purpose operating system?

    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.

  6. What hardware architectures does KasperskyOS support?

    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.

  7. Do you provide technical support for this product?

    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.

  8. Which programming language will your operating system be written in? Will it support existing applications?

    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.

  9. Is KasperskyOS Linux-based?

    No.

  10. How can a KOS image with applications be downloaded to a device?

    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.

  11. What about support for SMP (multi-core), synchronization?

    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.

  12. Is KasperskyOS User Mode POSIX-compliant? Which libc (newlib, glibc) library is supported? (Which POSIX API functions are not supported?)

    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.

  13. Is there support for graphics (at least for a frame buffer)? Which video cards do you support?

    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.

  14. Maybe you’ve already implemented kexec to Linux from your OS? I understand that completing the programming side is not a problem, but maybe it has already been implemented?

    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.

  15. Does the OS have support for C & C++? What compilers (brand and version) are used? What language standards are supported? Are there any limitations/exceptions to the language standards?

    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.

  16. Does it have a VFS layer (in other words, an abstraction layer that defines an API for accessing various file systems)?
    a. If VFS is present, we need to review the header files related to the VFS layer to understand the interface that our solution must implement
    b. If VFS is not included, does the OS support any other file system (e.g. FAT32)?
    If an FS is supported, please share the API for accessing that file system (header files). If NO FS is supported, we can offer UFSD SDK (a C++ library)

    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: a) linked into your application (means no IPC, isolated FS tree; fast); b) linked into a separate process (means IPC, i.e. each call can be controlled by our security system; common FS tree; slower); c) you can implement your own VFS layer, so every application in the system can interact with your VFS without recompiling (there is an example of such a scenario in our SDK); d) you can combine all of the aforementioned methods.

  17. Which file systems should be supported by Paragon UFSD™? For NTFS it’s clear, but what about HFS+, exFAT and others?

    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.).

  18. Which scenarios related to FS are planned (e.g. media playback and/or recording, file backup/restore, torrent download 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.

  19. Can a test environment and/or samples be provided?

    Yes, we can provide one of the latest versions of our SDK, but only after a formal release.

  20. What debugging and profiling tools are included in the SDK? How is application debugging performed?

    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:

    • Emulator (QEMU) + GDB
    • Hardware + GDB (via UART)