Monolithic kernel

Abstract: Monolithic operating system designs undermine the security of computing systems by allowing single exploits anywhere in the kernel to enjoy full supervisor privilege. The nested kernel operating system architecture addresses this problem by "nesting" a small isolated kernel within a traditional monolithic kernel. The "nested kernel" interposes on all updates to virtual memory translations to assert protections on physical memory, thus significantly reducing the trusted computing base for memory access control enforcement. We incorporated the nested kernel architecture into FreeBSD on x86-64 hardware while allowing the entire operating system, including untrusted components, to operate at the highest hardware privilege level by write-protecting MMU translations and de-privileging the untrusted part of the kernel. Our implementation inherently enforces kernel code integrity while still allowing dynamically loaded kernel modules, thus defending against code injection attacks. We also demonstrate that the nested kernel architecture allows kernel developers to isolate memory in ways not possible in monolithic kernels by introducing write-mediation and write-logging services to protect critical system data structures. Performance of the nested kernel prototype shows modest overheads:

Abstract: Most operating systems enforce process isolation through hardware protection mechanisms such as memory segmentation, page mapping, and differentiated user and kernel instructions Singularity is a new operating system that uses software mechanisms to enforce process isolation A software isolated process (SIP) is a process whose boundaries are established by language safety rules and enforced by static type checking SIPs provide a low cost isolation mechanism that provides failure isolation and fast inter-process communicationTo compare the performance of Singularity's SIPs against traditional isolation techniques, we implemented an optional hardware isolation mechanism Protection domains are hardware-enforced address spaces, which can contain one or more SIPs Domains can either run at the kernel's privilege level or be fully isolated from the kernel and run at the normal application privilege level With protection domains, we can construct Singularity configurations that are similar to micro-kernel and monolithic kernel systems We found that hardware-based isolation incurs non-trivial performance costs (up to 25--33%) and complicates system implementation Software isolation has less than 5% overhead on these benchmarksThe lower run-time cost of SIPs makes their use feasible at a finer granularity than conventional processes However, hardware isolation remains valuable as a defense-in-depth against potential failures in software isolation mechanisms Singularity's ability to employ hardware isolation selectively enables careful balancing of the costs and benefits of each isolation technique

Abstract: In traditional operating systems, there are many weak points. In monolithic kernel-based operating systems, many functions have been implemented in the kernel to satisfy various requests from user applications. As a result, the kernel itself has become more complex and bigger than expected, and many weak points have been appeared in it. A microkernel-based operating system improves the weak points of a monolithic kernel-based one by separating the kernel itself from the kernel functions (called system servers). In such a system, a microkernel architecture is supplied for flexibility and expansibility, but there are weak points in that structure too. In order to get over the weak points of traditional operating systems, a new operating system architecture is needed. In this paper, a new kernel structure is suggested. It enables one to reconstruct kernel functions dynamically at execution time, but there are some problems with realizing such a kernel. In this paper, we describe how to divide kernel functions into multiple modules and how to implement the suggested kernel. By implementing and evaluating a prototype of the kernel, the effectiveness of the suggested kernel architecture is confirmed.

Abstract: The monolithic kernel architecture is significant in the real world due to the large amount of working and proven code. However, the architecture is not without problems: testing and development is difficult, virtualizing kernel services can be done only by duplicating the entire kernel, and security is weak due to a single domain where all code has direct access to everything. Alternate kernel architectures such as the microkernel and exokernel have been proposed to rectify these problems with monolithic kernels. However, alternate system structures do not address the common desire of using a monolithic kernel when the abovementioned problems do not apply. We propose a flexible anykernel architecture which enables running kernel drivers in a variety of configurations, examples of which include microkernel-style servers and application libraries. A monolithic kernel is shown to be convertible into an anykernel with a reasonable amount of effort and without introducing performance-hindering indirection layers. The original monolithic mode of operation is preserved after the anykernel adjustments, and alternate modes of operation for drivers are available as a runtime choice. For non-monolithic modes of operation, the rump kernel is introduced as a lightweight container for drivers. A rump kernel runs on top of a hypervisor which offers high-level primitives such as thread scheduling and virtual memory. A production quality implementation for the NetBSD open source OS has been done. The anykernel architecture and rump kernels are evaluated both against four years of real-world experience from daily NetBSD development as well as against synthetic benchmarks.; Monoliittisen ytimen kayttojarjestelmat ovat merkittavia, koska ne sisaltavat suuren maaran olemassaolevia ja testattja ajureita. Monoliittinen arkkitehtuuri ei kuitenkaan ole ongelmaton: virtualisointi onnistuu vain virtualisoimalla ydin kokonaisuutena, ytimen testaus on vaikeaa ja tietoturva on heikkoa johtuen siita, etta ytimessa suoritettavalla ohjelmistolla on suora paasy kayttojarjestelman kaikkiin osiin. Vaihtoehtoisia ydinarkkitehtuureita, kuten mikroydin ja eksoydin, on ehdotettu korjaamaan monoliittisen arkkitehtuurin ongelmia. Vaihtoehtoisissa malleissa on kuitenkin ongelmana se, etteivat ne tue yleista halua kayttaa monoliittista ydinta, kun yllamainitut ongelmat eivat ole relevantteja. Tassa tyossa luodaan joustava jokaydin. Se mahdollistaa ajureiden suorittamisen monissa konfiguraatioissa, esimerkkeja joista ovat mikroydin-tyyliset palvelimet ja sovelluskirjastot. Monoliittisen ytimen muuntamisen jokaytimeksi naytetaan onnistuvan saadyllisella vaivalla ilman suorituskykya heikentavia abstraktioita. Mahdollisuus suorittaa ajureita monoliittisessa ytimessa sailyy ja muut suorituskonfiguraatiot tarjotaan ajonaikaisena valintana. Muita kuin monoliittisista suorituskonfiguraatiota varten maaritellaan tynkaydin, joka on ajoymparisto ajureille. Tynkaytimen suoritus tapahtuu hyperkaihtimen paalla. Hyperkaihdin tarjoaa tynkaytimelle korkean…