SAFETY CRITICAL BLOG: Microkernels, de-centralized government and social order
SAFETY CRITICAL BLOG: In the early days, we lived in a physical world. Everything ran in supervisor mode, much like a commune. Unfortunately, with no leader, if was difficult to preserve order and contain errant and malicious code, so chaos and mischief ensued. A bad pointer was all that was needed to bring the most sophisticated equipment to its knees, witness the Mars Rover and its maddening encounter with that nettlesome rock.
Enter the monolithic OS, where we started to use the memory management unit to isolate applications from each other and the kernel. The kernel, running in supervisor mode, was the boss, executing all the special instructions needed to control and access physical addresses (memory and IO), switch application context, pass interrupts, etc.
Individual applications, placed in their own sandboxes, were free to execute according to the capabilities granted by the kernel. However, the applications were isolated from each other, and should an application behave badly, the MMU (police) would prevent that behavior from spreading to other applications. Individual applications might crash, but the system as a whole would survive.
The new dictatorship brought order and safety to chaos and mayhem, but like most centralized government, was unwieldy and inefficient. It was a monolithic mass of code, and all of the services (i.e. TCP/IP stack, IPC mechanisms) and hardware device drivers operated at the highest level of privilege. As a result, every application that used them, however non-critical, had to be tested and verified at the highest design assurance level (DAL). Any change to the monolithic mass, however small, necessitated retesting and reverification of the entire mass.
The founders of our great country foresaw the peril of concentrated power and authority. Yes, there needed to be a strong central authority to provide for the national defense and regulate commerce between the states, but local matters, they recognized, were best handled locally by those most familiar with local circumstances. And so, after some fits and starts, our federalist system came to be, with certain enumerated powers granted the central federal government, the rest delegated to the states and the people.
The founders, evidently, were more than just farmers, merchants, and politicians. They were first-generation visionary embedded systems developers, for how else in their infinite wisdom could they have foreseen the modern safety-critical microkernel, the very embodiment of computational federalism. The modern microkernel, as our forefathers envisioned, provides only the core services required by applications, such as memory mapping, passing interrupts, and enforcing global rules. The drivers for non-critical services such as I/O and networking are implemented as independent servers, each mapped to its own address space. In this way, device drivers are isolated from not only the kernel, but also other device drivers and applications, thereby minimizing their fault impact.
The microkernel approach also simplifies testing and verification, not only during the initial design phase, but also for future modifications. With a microkernel architecture, drivers are separate from the kernel and operate at the privilege level of the application that is using it. Moreover, the driver need only be certified to the design assurance level of the highest DAL application using it. This greatly reduces the amount of verification and certification work required to design and modify drivers and applications.
Another day, we will discuss how privileged operations like DMA are handled by distributed device drivers (very cool, think of it as a Department of Homeland Security that works for the people). Meanwhile, give your applications a decentralized government that distributes power and authority for maximum safety, reliability and efficiency. Buy a microkernel OS for your next safety-critical device. And don’t forget to vote in your local elections on November 4th.