Operating Systems and Systems Software

Introduction and Context

An operating system (OS) is the principal systems-software layer that coordinates hardware, provides common services to application programs, and creates abstractions that make computing systems usable. It is simultaneously a resource manager, a control program, a security boundary, and an execution environment. Systems software more broadly includes operating systems, device drivers, firmware, language translators, linkers, loaders, utilities, virtual machines, and runtime libraries.

The importance of operating systems extends beyond personal computers. Servers, mobile devices, embedded controllers, cloud platforms, industrial systems, and autonomous machines all depend on operating-system principles. At postgraduate level, the subject should be understood not merely as a collection of commands or interfaces, but as a set of design choices involving concurrency, protection, performance, reliability, and abstraction.

An OS must reconcile competing objectives. It should maximize useful work, respond quickly to interactive requests, use memory efficiently, isolate failures, protect data, and remain maintainable across changing hardware. These objectives often conflict. For example, aggressive caching may improve performance but increase the cost of recovery after a failure; virtualization improves isolation but introduces management and performance overhead.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain the role, structure, and evolution of operating systems and systems software.
2. Distinguish user mode from kernel mode and explain system calls.
3. Analyze process, thread, scheduling, synchronization, and interprocess communication mechanisms.
4. Explain virtual memory, file systems, storage management, and device I/O.
5. Compare operating-system architectures and virtualization models.
6. Evaluate security, reliability, performance, and governance trade-offs.
7. Apply operating-system concepts to a realistic systems-design problem.

1. The Operating System as an Abstraction and Resource Manager

An operating system presents abstractions that simplify hardware. A process abstracts a running program; a virtual address space abstracts physical memory; a file abstracts persistent storage; and a socket abstracts communication endpoints. These abstractions permit software to be written without depending on every hardware detail.

The OS also allocates scarce resources. The major resources are processor time, main memory, secondary storage, peripheral devices, and communication channels. Allocation policies must address fairness, priority, throughput, latency, and safety. A high-performance batch server may favor throughput, while an interactive system may favor response time.

A useful conceptual distinction is:

• Mechanism: how an operation is implemented, such as a timer interrupt or page table.
• Policy: which choice is made, such as which process runs next or which page is evicted.

Separating mechanism from policy improves portability and allows policies to evolve without redesigning hardware-control mechanisms.

Privilege and protection

Modern processors usually support at least two privilege levels. User mode restricts direct access to sensitive instructions and hardware. Kernel mode permits the operating system to manage memory-management units, interrupt controllers, device registers, and scheduling. A user program requests privileged services through a controlled transition called a system call.

A typical system-call sequence is:

1. An application invokes a library wrapper.
2. Arguments are placed in registers or memory according to an application binary interface.
3. A special instruction transfers control to the kernel.
4. The kernel validates arguments and permissions.
5. The requested operation is performed or initiated.
6. A return value and error indication are passed back to user mode.

This boundary is essential for protection. If ordinary applications could freely modify page tables or device registers, one faulty or malicious program could compromise the entire machine.

Interrupts and exceptions

An interrupt is an event, generally generated asynchronously by hardware, that requests processor attention. A network card may interrupt when a packet arrives, and a timer may interrupt to support preemptive scheduling. An exception is a processor-detected event associated with the current instruction, such as division by zero, an invalid instruction, or a page fault. Both cause controlled transfer to an operating-system handler.

The OS saves sufficient processor state, identifies the event, executes a handler, and then either resumes the interrupted activity or terminates it. Excessive interrupts can reduce performance, so systems use techniques such as batching, interrupt coalescing, and polling in appropriate contexts.

2. Systems Software and the Translation Toolchain

Systems software connects human-readable programs to executable machine behavior. A compiler translates a source language into assembly or object code. An assembler converts assembly into machine-code object files. A linker combines object files and libraries, resolves symbols, and produces an executable or shared library. A loader maps the executable into memory, performs remaining relocation or dynamic linking, and starts execution.

A simplified toolchain is:

Source code → compiler → assembly/object code → assembler → object file → linker → executable → loader → process

A static library is incorporated into an executable during linking. A shared library is loaded or mapped at run time and can be shared by multiple processes. Static linking can simplify deployment but may increase executable size and complicate security updates. Dynamic linking reduces duplication and supports modular updates, but introduces dependency and compatibility issues.

Language runtimes provide services such as garbage collection, exception handling, reflection, and just-in-time compilation. A virtual machine, such as a managed-language runtime, may execute bytecode on different operating systems while preserving a common programming model. These layers illustrate that “the operating system” is part of a broader software stack rather than an isolated program.

3. Operating-System Organization

Monolithic kernels

In a monolithic kernel, major services—including process management, memory management, file systems, networking, and drivers—execute in kernel space. This design can be efficient because services communicate through direct procedure calls. Its principal weakness is that a defect in one privileged component can corrupt the whole kernel.

Layered systems

A layered design organizes functionality into levels, with each layer using services of lower layers. Layering improves conceptual clarity and testing, but strict boundaries may create inefficiency or make cross-layer optimizations difficult.

Microkernels

A microkernel keeps only essential mechanisms, such as low-level address-space management, scheduling, and interprocess communication, in privileged mode. File systems and drivers may execute as user-space servers. This can improve fault isolation and security, although message-passing and context-switch overhead may complicate performance engineering.

Modular and hybrid kernels

Loadable kernel modules permit components to be added without rebuilding the entire kernel. Hybrid systems combine monolithic performance techniques with selected microkernel ideas. There is no universally optimal architecture; the appropriate choice depends on latency requirements, hardware diversity, assurance goals, and maintenance constraints.

4. Processes, Threads, and Concurrency

A program is a passive set of instructions and data. A process is an executing program together with its address space, registers, open resources, security credentials, and operating-system metadata. The process control block records information needed to suspend and resume a process.

A process commonly moves among states such as new, ready, running, blocked, and terminated. A running process becomes blocked when it waits for I/O or synchronization. It returns to the ready state when the event completes.

A thread is a unit of execution within a process. Threads in the same process share code, data, and open files, but each has its own stack, registers, and program counter. Multithreading can improve responsiveness and exploit multicore processors. It also introduces races and synchronization complexity.

Context switching

A context switch saves the execution state of one thread and restores the state of another. It enables multitasking but consumes time and may disturb processor caches and translation-lookaside buffers. Consequently, a system with more threads is not automatically faster.

Scheduling

The scheduler selects a runnable thread. Common criteria include:

• CPU utilization: fraction of time the processor performs useful work.
• Throughput: completed jobs per unit time.
• Turnaround time: completion time minus submission time.
• Waiting time: time spent in the ready queue.
• Response time: time from request submission until initial service.
• Fairness: equitable access to processor time.

For a set of jobs, average waiting time is:

Here, n is the number of jobs. The expression assumes that all waiting times are measured using the same scheduling interval and definition.

First-come, first-served (FCFS) is simple but can produce the convoy effect: short jobs wait behind a long job. Shortest-job-first (SJF) minimizes average waiting time when all jobs are available simultaneously and their CPU burst lengths are known exactly; this condition is rarely fully available in practice. Round-robin assigns each runnable thread a time quantum and is appropriate for interactive systems, although a quantum that is too small causes excessive context switching and one that is too large approaches FCFS. Priority scheduling supports differentiated service but may cause starvation; aging gradually increases the priority of waiting work.

Synchronization and race conditions

A race condition occurs when the result depends on the timing of concurrent operations. A critical section is code that accesses shared state and must satisfy mutual exclusion. A correct solution should provide:

1. Mutual exclusion: at most one thread enters the critical section.
2. Progress: if no thread is inside, an eligible waiting thread can proceed.
3. Bounded waiting: no thread waits indefinitely under the stated assumptions.

A mutex provides ownership-based mutual exclusion. A semaphore is an integer synchronization abstraction manipulated through atomic wait and signal operations. A condition variable allows a thread to sleep until a predicate becomes true; it is normally used with a mutex and must be checked in a loop because wake-up does not itself prove that the predicate holds.

A deadlock exists when each process in a set waits for an event that only another process in that set can cause. Four necessary conditions are mutual exclusion, hold and wait, no preemption, and circular wait. Deadlock can be handled by prevention, avoidance, detection and recovery, or by designing systems so that deadlocks are impossible under known resource rules. The banker’s algorithm is an avoidance method requiring advance knowledge of maximum demands, an assumption often unsuitable for general-purpose software.

5. Interprocess Communication and Distributed Coordination

Processes communicate through shared memory or message passing. Shared memory is efficient after setup but requires synchronization. Message passing provides clearer isolation and may operate across machines, but serialization and communication latency add overhead.

Common mechanisms include pipes, message queues, signals, shared-memory regions, remote procedure calls, and sockets. A socket endpoint is characterized by an address and transport protocol; TCP provides a reliable ordered byte stream, whereas UDP provides datagrams without the same delivery guarantees.

In distributed systems, there is no single perfectly synchronized global clock. Timeouts therefore indicate suspicion rather than proof of failure. Systems must consider partial failure, duplicate messages, network partitions, and replay. Idempotent operations—operations that can safely be repeated—are especially valuable in unreliable environments.

6. Memory Management and Virtual Memory

The OS assigns each process a virtual address space. Virtual memory separates the addresses used by a program from physical frames in main memory. This supports isolation, relocation, controlled sharing, and execution of programs whose active working set exceeds available physical memory.

With paging, virtual memory is divided into fixed-size pages and physical memory into frames. A page table maps virtual page numbers to frame numbers and records permissions and status bits. A translation lookaside buffer (TLB) caches recent translations.

For a virtual address space of size 2^m bytes and page size 2^p bytes, the page offset contains p bits and the virtual page number contains m − p bits. The number of pages is 2^m−p. These relationships assume a byte-addressable memory and a power-of-two page size.

A page fault occurs when a referenced page is not currently resident or lacks the required permission. The kernel validates the reference, locates or creates the page, obtains a free frame or evicts another page, updates the page table, and restarts the interrupted instruction.

Page-replacement policies

FIFO evicts the page that has been resident longest but can display Belady’s anomaly, in which adding frames increases faults. LRU evicts the page least recently used and is often effective because of temporal locality, although exact implementation can be expensive. The theoretical optimal policy evicts the page whose next use is farthest in the future; it is not implementable online but provides a benchmark.

The effective access time for a simplified TLB model can be expressed as:

Here, h is the TLB hit ratio, T_TLB is TLB lookup time, and T_M is one main-memory access time. The formula assumes a one-level page table, no page faults, and that a TLB miss requires one page-table access followed by one data access. Real systems may include cache effects, multilevel tables, and page-walk caching.

Worked example. Suppose h = 0.98, T_TLB = 10 ns, and T_M = 100 ns. Then:

EAT = 0.98(10 + 100) + 0.02(10 + 200) = 107.0 + 4.2 = 111.2 ns.

The result is an average under the stated model, not a universal measurement of a real processor.

Thrashing occurs when a system spends most of its time servicing page faults rather than executing useful instructions. Working-set reasoning, sufficient physical memory, controlled multiprogramming, and sound locality-aware design reduce this risk.

7. File Systems and Storage

A file system provides naming, organization, protection, allocation, and persistence for data. Its abstractions commonly include files, directories, metadata, permissions, links, and file descriptors. A file descriptor is a process-local handle referring to an open-file object maintained by the kernel.

File allocation may use contiguous, linked, or indexed structures. Contiguous allocation gives excellent sequential and random-access performance but suffers from external fragmentation and difficult growth. Indexed allocation supports flexible growth but requires index blocks and additional lookups. Modern file systems use extent-based allocation, journaling or copy-on-write techniques, checksums, caching, and sophisticated allocation policies.

A write operation may be buffered in memory before reaching stable storage. Therefore, “write completed” can mean that data reached a cache rather than durable media. Applications requiring durability must use the appropriate flush or synchronization semantics and must understand the storage device’s guarantees.

A journaling file system records metadata or updates in a recoverable log before applying them. Journaling improves consistency after crashes but does not automatically guarantee that every application data block is durable. File-system integrity, backup, replication, and disaster recovery are related but distinct concerns.

Storage performance is influenced by access latency, bandwidth, queue depth, locality, and parallelism. Solid-state storage removes mechanical seek delays but does not eliminate controller overhead, garbage collection, endurance limits, or the need for reliable persistence semantics.

8. Device Management and I/O

Devices vary widely in speed, data representation, and control interfaces. Device drivers translate generic OS requests into device-specific operations. The OS may use programmed I/O, interrupt-driven I/O, or direct memory access (DMA). With DMA, a controller transfers data between a device and memory while the processor performs other work; completion is commonly reported by an interrupt.

Buffering accommodates speed mismatches, caching retains likely-to-be-reused data, and spooling queues work for devices such as printers. I/O scheduling can reorder requests to improve locality or fairness, but reordering must respect correctness requirements and device semantics.

A driver is part of the trusted computing base when it executes with kernel privilege. Driver quality is therefore a major reliability and security concern. Modern designs increasingly use user-space drivers, capability restrictions, and hardware virtualization to reduce the impact of driver faults.

9. Protection, Security, and Reliability

Protection governs how subjects—users, processes, or services—may access objects such as files, memory regions, devices, and network endpoints. Authentication establishes identity; authorization determines permitted actions; auditing records relevant events. The principle of least privilege grants only the access necessary for a task.

Access-control lists associate permissions with objects, while capabilities associate unforgeable authority with subjects. Sandboxing constrains a program’s resources and interfaces. Mandatory access-control systems enforce policy independently of individual object owners, which is valuable in high-assurance environments.

Important threats include privilege escalation, memory-safety vulnerabilities, insecure drivers, supply-chain compromise, credential theft, ransomware, and denial of service. Defenses include secure boot, code signing, address-space layout randomization, non-executable memory, control-flow integrity, patch management, isolation, strong authentication, encryption, and monitoring. No single defense is sufficient; security is a system property.

Reliability requires fault detection, containment, recovery, and verification. Checkpointing, replication, watchdog timers, transactional updates, graceful degradation, and tested backups are common techniques. Availability alone is not equivalent to correctness: a system that remains online while corrupting records is not reliable.

Operating systems also raise ethical and governance questions. Telemetry should be proportionate, transparent, and protected. Access logs may support accountability but can expose sensitive personal information. Automated resource allocation should be auditable when it affects employment, access to services, or safety. Administrators must define retention, consent, incident response, and change-management policies.

10. Virtualization, Containers, and Cloud Systems

Virtualization presents a logical computing environment over physical resources. A hypervisor may be type 1, running directly on hardware, or type 2, running above a host operating system. A virtual machine emulates or exposes virtual hardware and runs a guest OS. Benefits include isolation, consolidation, portability, snapshots, and controlled experimentation.

Virtualization introduces overhead in CPU scheduling, memory translation, device emulation, and I/O. Hardware support such as nested page tables and I/O virtualization reduces, but does not eliminate, this cost.

Containers isolate processes while sharing the host kernel. Namespaces provide views of processes, networks, mounts, and users; control groups constrain and measure resource use. Containers usually start faster and consume fewer resources than full virtual machines, but their shared-kernel model creates a different security boundary. A container is not automatically a virtual machine.

Cloud operating environments extend these ideas through orchestration, elastic resource allocation, service discovery, observability, and automated recovery. Their operational challenges include noisy neighbors, hidden dependencies, jurisdictional data concerns, vendor lock-in, and complex failure modes.

11. Contemporary Developments and Research Directions

Modern operating-system research addresses heterogeneous processors, nonvolatile memory, confidential computing, disaggregated resources, energy-aware scheduling, real-time guarantees, and data-center-scale orchestration. Heterogeneous systems require schedulers to consider not just processor availability but also accelerator suitability, thermal constraints, and energy cost.

Confidential-computing technologies seek to protect data during processing through hardware-enforced trusted execution environments. They can reduce some threats from privileged software, but introduce new trust assumptions, side-channel concerns, and attestation-management requirements.

Artificial intelligence is relevant in operating systems primarily as an optimization and management technique. Machine-learning models may predict workload behavior, cache usefulness, failure risk, or resource demand. However, prediction errors can harm latency, fairness, or reliability. AI-assisted system management should therefore include confidence monitoring, safe fallbacks, reproducibility, and human-governed change control. An opaque model should not replace explicit safety constraints.

12. Case Study: Protecting a University Research Cluster

This is an illustrative case.

Background

A university operates a shared Linux-based research cluster used for computational science, machine learning, and student projects. Users submit jobs that compete for CPU, GPU, memory, and high-speed storage. The cluster has experienced long interactive delays, accidental exposure of private datasets, and occasional node failures caused by incompatible drivers.

Problem

The existing design gives users broad access to shared directories. Jobs are scheduled mainly by arrival order, and resource requests are often inaccurate. A faulty driver can crash a node, while a large memory workload causes paging and degrades unrelated jobs.

Analysis

The problem combines scheduling, protection, memory management, reliability, and governance. FCFS is inappropriate because jobs differ substantially in duration and resource demand. Broad file permissions violate least privilege. Inaccurate resource requests create overcommitment and unpredictable performance. Kernel-resident drivers enlarge the trusted computing base.

Approach and solution

The administrators introduce a scheduler with fair-share priorities, explicit CPU/GPU/memory requests, queue limits, and aging to prevent starvation. Control groups enforce memory and processor limits. Separate project namespaces and group-based access controls restrict datasets. Sensitive files are encrypted at rest, and access is audited.

The cluster uses tested driver versions and staged deployment. Where feasible, device access is mediated through isolated services. Node health checks remove failing machines from service automatically. A monitoring system records queue delay, job failure rate, memory pressure, and storage latency. Users receive documentation explaining resource requests and data-handling responsibilities.

Outcome

Interactive response improves because resource-intensive batch jobs no longer consume uncontrolled memory. Dataset exposure decreases through project-level permissions and auditing. Driver updates become reversible because they are tested in a staging pool. Some jobs take longer under fair-share limits, but the cluster’s overall predictability and utilization improve.

Learning points

1. Performance problems often arise from policy, not only hardware capacity.
2. Isolation must cover CPU, memory, storage, identity, and drivers.
3. Security controls should be integrated with scheduling and operations.
4. Metrics must measure user experience and reliability, not utilization alone.
5. Governance—documentation, review, and incident response—is part of systems engineering.

Best Practices for Systems Design

A robust systems-software design should:

• define protection boundaries explicitly;
• separate policy from mechanism where practical;
• minimize privileged code and validate all external input;
• use measured workload data rather than assumptions;
• design for failure, recovery, and observability;
• document persistence and consistency guarantees;
• test race conditions, overload, partial failure, and upgrades;
• apply least privilege and maintain auditable changes;
• use automation with safe rollback paths;
• evaluate total cost, energy use, accessibility, and long-term maintainability.

Challenges and Limitations

Operating systems cannot remove fundamental trade-offs. Strong isolation may reduce performance or convenience. Exact scheduling fairness is difficult when workloads have different priorities and resource profiles. Virtual memory can hide capacity problems until paging becomes catastrophic. Distributed systems cannot infer global state perfectly under arbitrary communication failures. Security mechanisms can introduce usability burdens, and patches may themselves create compatibility risks.

Abstractions also leak. Cache behavior, page faults, scheduling delays, storage durability, and network latency can become visible to applications. Professional system design therefore requires understanding both the abstraction and the hardware realities beneath it.

Chapter Summary

Operating systems are privileged systems software that abstracts hardware, manages resources, and enforces protection. Their central mechanisms include processes, threads, interrupts, system calls, virtual memory, file systems, device drivers, and interprocess communication. Scheduling determines how computational work is shared, while synchronization controls concurrent access and prevents races, deadlocks, and starvation. Virtual memory provides isolation and flexible allocation through page tables, TLBs, and page replacement. File systems organize persistent data but require careful attention to caching, durability, recovery, and permissions.

Kernel architecture involves trade-offs among performance, fault isolation, modularity, and assurance. Virtual machines and containers extend operating-system abstractions into cloud and distributed environments. Security depends on privilege control, least authority, isolation, secure updates, and monitoring. Contemporary systems increasingly address heterogeneous hardware, confidential computing, energy efficiency, and AI-assisted management, but these developments introduce new trust and governance questions. Effective systems engineering combines mechanisms, policies, measurement, testing, and responsible administration.

Key Terms

Operating system: Privileged software that manages hardware and provides services to applications.

Systems software: Software that supports execution, translation, management, or operation of other software.

Kernel: Core privileged component of an operating system.

System call: Controlled interface through which a program requests a kernel service.

Interrupt: Asynchronous event that transfers control to an operating-system handler.

Process: An executing program together with its resources and execution state.

Thread: A schedulable execution unit within a process.

Context switch: Saving one execution context and restoring another.

Race condition: Behavior whose result depends on timing among concurrent activities.

Deadlock: A circular waiting condition in which no participant can proceed.

Virtual memory: Address-space abstraction that maps virtual addresses to physical memory.

Page: Fixed-size unit of virtual memory.

TLB: Cache of recent virtual-to-physical address translations.

File system: Software organization for naming, storing, protecting, and recovering data.

Device driver: Software translating OS operations into device-specific control.

DMA: Direct memory access performed by a device controller.

Hypervisor: Software or firmware that manages virtual machines.

Container: Isolated process environment sharing a host kernel.

Least privilege: Granting only the authority required for a task.

Control group: Mechanism for limiting and measuring resource use by processes.

Review Questions

Short Answer Questions

1. Why must operating systems distinguish user mode from kernel mode?
2. What is the difference between a process and a thread?
3. Define a race condition and identify one method for preventing it.
4. What role does a TLB play in virtual-memory systems?
5. Distinguish a virtual machine from a container.

Long Answer Questions

1. Explain the operating system as both an abstraction layer and a resource manager. Illustrate the tension between performance, fairness, and protection.
2. Compare monolithic, microkernel, layered, and modular architectures, including their principal advantages and limitations.
3. Explain process scheduling, synchronization, and deadlock management as related concurrency problems.
4. Describe paging, page faults, TLBs, and page-replacement policies. Include the assumptions behind effective-access-time analysis.
5. Discuss file-system reliability, storage durability, device management, and recovery after failure.

Analytical / Application Questions

1. A server has a high TLB hit ratio but still exhibits poor application latency. Analyze at least four possible causes across scheduling, memory, storage, and I/O, and propose measurements to distinguish them.
2. Design a protection and scheduling policy for a shared university computing cluster. State how you would handle fairness, sensitive data, memory pressure, faulty drivers, and auditability.
3. A company plans to replace virtual machines with containers to reduce deployment time. Evaluate the decision by analyzing performance, isolation, kernel dependence, operational complexity, and security assumptions.

Multiple Choice Questions with Answers

Question 1

Which mechanism provides a controlled transition from user mode to kernel mode?

A. A system call

B. A cache hit

C. A linker symbol

D. A file allocation table

Correct Answer: A. A system call

Question 2

Which scheduling policy assigns each runnable process a fixed time quantum?

A. Shortest-job-first

B. Round-robin

C. First-come, first-served

D. Static linking

Correct Answer: B. Round-robin

Question 3

Which condition is necessary for deadlock?

A. Unlimited preemption

B. Circular wait

C. Absence of shared resources

D. Guaranteed process termination

Correct Answer: B. Circular wait

Question 4

For a byte-addressable virtual address space of 2²⁰ bytes with page size 2¹² bytes, how many virtual pages exist?

A. 256

B. 1,024

C. 4,096

D. 65,536

Correct Answer: C. 4,096

Question 5

Using EAT = h(T_TLB + T_M) + (1−h)(T_TLB + 2T_M), with h=0.9, T_TLB=10 ns, and T_M=100 ns, what is the effective access time?

A. 110 ns

B. 119 ns

C. 120 ns

D. 210 ns

Correct Answer: B. 119 ns

Question 6

Which statement about the optimal page-replacement policy is correct?

A. It evicts the oldest page in memory.

B. It evicts the page least recently used.

C. It evicts the page whose next use is farthest in the future.

D. It always produces more faults than FIFO.

Correct Answer: C. It evicts the page whose next use is farthest in the future.

Question 7

What is the primary purpose of direct memory access?

A. To allow a device controller to transfer data to or from memory with limited CPU intervention

B. To translate source code into machine code

C. To enforce file permissions

D. To select the next process using the CPU

Correct Answer: A. To allow a device controller to transfer data to or from memory with limited CPU intervention

Question 8

Which statement best describes a container?

A. It always includes a complete independent kernel.

B. It isolates processes while generally sharing the host kernel.

C. It is a type of static library.

D. It can execute only one instruction at a time.

Correct Answer: B. It isolates processes while generally sharing the host kernel.

Question 9

Which principle grants a subject only the permissions required for its task?

A. Locality of reference

B. Least privilege

C. Dynamic linking

D. Preemptive scheduling

Correct Answer: B. Least privilege

Question 10

What is the main risk of placing a device driver in kernel space?

A. It cannot communicate with hardware.

B. A driver defect can compromise kernel integrity and the entire system.

C. It prevents all interrupt handling.

D. It necessarily eliminates DMA.

Correct Answer: B. A driver defect can compromise kernel integrity and the entire system.