kernel mode and memory protection [closed]

Question

in Operating System User mode application's virtual address space is private, one application cannot alter data that belongs to another application. Each application runs in isolation, and if an application crashes, the crash is limited to that one application. Other applications and the operating system are not affected by the crash

why in kernel mode OS don't protect memory and BOSD occur??

Answer 1

First, at some level you will always have a component that Cannot Fail™. If this component crashes, no recovery is possible. For example, if you trash the table of running processes, you can't rebuild this apart from rebooting. So even with memory protection limiting this component's crashes to affecting only itself, BSODs (or the equivalent) can occur.

But your point is a good one - there are a number of components that often can be reset without a catastrophic failure. Drivers, for example, or the networking stack. Indeed, there are OSes that do protection at this level - they are referred to as microkernel architectures.

The problem with microkernels, however, is performance. On x86 CPUs memory protection is achieved with two things - the Current Privilege Level (CPL, or 'ring'), a number between 0 (maximum access) and 3 (user mode), and the Page Table. The page table maps virtual addresses to physical addresses, and sets access restrictions on each page (4096-byte block of memory). Each process has its own page table, and each page in the page table can be restricted by setting a maximum CPL, read-only flag, no-execute flag, or no-access flag.

Changing your CPL is a relatively fast operation (although there are security restrictions on how and when you're allowed to do so). Changing the page table, however, is quite expensive, as it requires clearing a cache on the CPU called the Translation Lookaside Buffer (TLB).

Typically in a normal OS, the OS will reserve the lowest X GB of memory for user processes (3GB is usually the number chosen for 32-bit architectures). The upper (4 - X) GB are directly mapped to the first (4 - X) GB of physical memory, and restricted to CPL 0 ('ring 0') only. Thus, the kernel can put its private datastructures in the upper 1GB or so and always access them at the same virtual address, no matter what process is running. If a process makes a syscall that requires half a dozen subsystems to do something, no problem - you can just call functions between them.

However, in a microkernel system, each kernel subsystem gets its own page table, and its own address mappings. To service a user call, the CPU might need to make quite a few page table changes, and this performance hit adds up. Moreover, each subsystem needs to be prepared to deal with failures of its dependencies, increasing the complexity of the system. Because of these problems, microkernels, by and large, have been only used as research and toy OSes (eg, minix, GNU HURD).

That said, in recent years, there has been some blurring of the line between macro- and micro-kernels. For example, in Windows 7, the graphics driver is in fact isolated from the rest of the kernel; if it crashes, the system can recover. In Linux and OS X, FUSE can load filesystem drivers in userspace; the NTFS driver on these systems, in fact, uses this mechanism.