The kernel of an operating system is its key architectural component, which links the software (e.g. user applications) and hardware (memory, CPU and other resources).
There has been debate around approaches to OS kernel design for years. Different approaches have their strengths and weaknesses, their ideal applications and specific problems they aim to solve. Therefore, the choice of OS kernel architecture must be based on intended use and security requirements.
The vast majority of operating systems have monolithic kernels (all OS functions run in a single space), microkernels (the kernel performs only a minimal set of functions, and most services are allocated to separate entities), or hybrid kernels that combine elements of both.
Many of the world’s most popular operating systems (including Windows 9x, FreeBSD, Linux, Android, etc.) are built on monolithic kernels. As a rule, developers and users find it relatively easy to interact with operating systems using this type of architecture. It allows for a variety of service APIs and places no restrictions on compatible devices or applications.
The flip side of that versatility is the difficulty in ensuring reliability and security. It is commonly understood that the number of coding errors, including those that result in vulnerabilities, is in direct proportion to the size of the programming units the kernel is built with. The level of security is also affected by the variety and total number of interfaces: the bigger the number, the broader the attack surface.
The large attack surface is also due to a multitude of heterogeneous services running within one address space simultaneously: protocol implementations, file systems, device drivers, etc. Failure of any of these services leads to the “blue screen of death” — a complete system failure.
Hybrid kernel-based operating systems are also often chosen for user IT systems. This architecture combines features of the monolithic and microkernel-based architectures. This means that most system functions run in a monolithic kernel, but as in microkernel-based operating systems, some of these functions run as separate programs in their own address spaces and interact through messaging, while a large share of the system services and drivers work in the form of user mode processes.
Hybrid kernel-based operating systems include, for example, iOS, MacOS X, Windows NT and DragonFly BSD. Hybrid architecture allows the operating system to leverage the advantages of a microkernel, while maintaining its stable monolithic kernel code where possible. The information security issues associated with a large attack surface remain unresolved in this type of system, however. Because of this, the kernel codebase cannot be considered trusted, which means it cannot be guaranteed to have no vulnerabilities. In addition, despite the use of microkernel architecture features, it is impossible for a hybrid OS to achieve a high level of security due to a lack of complete isolation of user processes from system processes.
A common property of microkernels is their small size. With respect to software, this means that its functions and architecture can be understood by a human without the need for a technical manual.
Despite the popularity of monolithic and hybrid kernel-based operating systems, it is microkernel architectures that are best suited for operating systems with increased reliability and security requirements.
Microkernels provide a minimal set of basic process management functions and hardware abstractions. Most of the remaining hardware and software support is done through special processes that run outside of the kernel address space. This allows the attack surface to be reduced significantly. In addition, the smaller the codebase of the OS kernel, the easier it is to monitor and check for errors, both manually and automatically. But it is not enough to provide an optimal amount of code for each software module: the interfaces between modules also need to remain low complexity.
In addition to running traditional microkernel functions, KasperskyOS also implements interprocess communication (IPC) in the context of dividing the operating system environment into domains (processes). The flow of data between them is monitored by a special framework called Kaspersky Security System.
KasperskyOS combines all the benefits of a state-of-the-art microkernel-based operating system, while creating an optimized environment for computing security verdicts for all system operations with Kaspersky Security System:
The KasperskyOS microkernel contains only a few thousand lines of code organized into optimal-sized modules. This is enough to ensure correct functioning of kernel mechanisms and the absence of undocumented features
All interprocess communication passes through the KasperskyOS microkernel and can only have one format: messaging. This ensures synchronized and transparent data transfer
By monitoring the correctness of the way KasperskyOS components "talk" to one another, the microkernel works in conjunction with Kaspersky Security System to block potentially dangerous actions before they are executed
Our microkernel guarantees separation of security domains and isolation of security mechanisms from other functional components: events in the latter cannot affect the former, and vice versa
Interprocess communication that is unauthorized or does not comply with security policies is impossible
Our microkernel does not collect or transmit data — this can be easily confirmed by reviewing the source code. All other components, such as drivers, system services, applications, etc., are moved out of the kernel and isolated, and their behavior is strictly limited by security policies. Security policies are written in a high-level language and collected in a specially designed component, regardless of the functional logic of the solution. If any of the system’s components attempts to store any data and/or send it somewhere, it will not be able to do so unless it is specified in a security policy defined for the solution. This approach makes it easy to conduct security audits.
" alt=""/>
" alt=""/>
