Modular and Monolithic Kernels in Redhat Linux

The kernel is the Linux operating system's core component. It is responsible for managing system memory, scheduling processes to run, and accessing the system's hardware on behalf of the users. As you can imagine, the kernel has a big job to do and needs to operate efficiently. One way to increase efficiency is to reduce the kernel's total memory requirement, allowing it to focus on managing processes' memory and not its own. To reduce the memory requirement we have to remove unnecessary kernel components.

A modular kernel allows an administrator to add functionality only when required. Keeping only what is necessary in kernel memory reduces the kernel's memory footprint^[1] and increases its overall performance.
Each kernel module contains code to handle some necessary system functionality. Device drivers^[2], for example, are common modules: a device driver such as a network module provides the support for a particular brand of network card. Modular kernels require a small amount of time to load modules. However, if the kernel was constantly loading and unloading modules, it would eventually spend more time processing load and unload requests than handling its other responsibilities.
To address this issue, the Linux kernel only loads modules when the system needs the functionality. Once loaded, a module remains in the kernel until explicitly removed. If another resource needs the module, the kernel can create another instance^[3] to meet the demand. This scheme prevents the kernel from needing to rapidly load and unload modules. For example, a red car is an instance of the general "car" object, and you can identify the car by its red characteristic. The kernel shuffles processes^[4] around very quickly, simulating "simultaneous" program execution.

• Monolithic Kernels A monolithic kernel is the exact opposite of a modular kernel. All support for system functionality, such as device drivers, is built directly into the kernel. Because the kernel supports all conceivable devices, especially those rarely used, kernel memory is wasted on unused support. The image below illustrates the difference between modular and monolithic kernels.

The "kernel mode design" in operating systems has several significant security implications:

1. Increased Privilege Exposure
   • Risk: Kernel mode provides unrestricted access to hardware resources, which means any code running in kernel mode has full system privileges. If this code is compromised, an attacker gains control over the entire system.
   • Mitigation: Careful design and rigorous testing of kernel code, along with minimizing the use of kernel mode for non-essential tasks, can reduce this risk.
2. Broader Attack Surface
   • Risk: The kernel manages core system operations like memory management, process scheduling, and I/O management. Any vulnerability here could be exploited to bypass security measures like sandboxing or memory protection.
   • Mitigation: Modern operating systems often implement microkernels or hybrid kernels where only the most essential services run in kernel mode, reducing what's exposed in the kernel space.
3. Memory and Buffer Management
   • Risk: Kernel mode operations often deal with low-level memory management. Errors like buffer overflows in kernel code can lead to arbitrary code execution with kernel privileges.
   • Mitigation: Use of safe coding practices, extensive use of static and dynamic code analysis tools, and the adoption of hardware features like DEP (Data Execution Prevention) can help.
4. Driver Security
   • Risk: Kernel mode drivers, which are essential for hardware interaction, operate with high privileges. A flawed or malicious driver can compromise system integrity.
   • Mitigation: Driver signing, sandboxing where possible, and regular updates to patch known vulnerabilities are critical.
5. Isolation and Containment
   • Risk: If the kernel is compromised, traditional containment strategies like user-space isolation become ineffective, as the attacker has access to all memory and can manipulate running processes.
   • Mitigation: Implementing hardware-based security features like Intel SGX (Software Guard Extensions) or ARM TrustZone can provide an additional layer of isolation even against kernel-level attacks.
6. Update and Patch Management
   • Risk: Patching kernel vulnerabilities can be complex and risky; it requires rebooting or using live patching mechanisms that themselves could introduce security issues if not designed properly.
   • Mitigation: Strategies include the use of live patching technologies, ensuring updates are thoroughly tested, and maintaining a rigorous schedule for applying security patches.
7. Audit and Logging
   • Risk: Since kernel mode operations are privileged, logging and auditing at this level can be challenging, leading to potential blind spots in system monitoring.
   • Mitigation: Enhanced kernel logging that's secure, tamper-evident, and comprehensive can help in post-incident analysis and real-time threat detection.

In summary, while kernel mode is indispensable for system performance and functionality, it necessitates stringent security measures. Operating systems are progressively moving towards designs that minimize kernel mode operations, employ more robust security checks, and leverage hardware for additional security layers to mitigate these risks.

In reality, most kernels are not strictly modular or monolithic, but are a reasonable mixture.
It makes sense to include some functionality directly in the kernel. For example, frequently used or boot-required functionality. It also makes sense to leave unused or rarely used code modular. For example, you might not have a ZIP drive now, but in the future you may, so building a module for it now and loading it when needed saves you some work later. You should always build mostly modular kernels.
The next lesson shows you how ton work with kernel modules.

[1]Memory footprint:The total amount of physical and swap memory a process uses.

[2]Device drivers : A unit of code written to interact with a specific hardware device.

[3]Instance: A particular session of any object, where each session has particular characteristics that identify it uniquely.

[4]Process : The computer's representation of a task. When a program is run from the command line, the binary is loaded into memory as a "process."