Questions: Kernel Mode and Privilege Levels

Question 1

A user-mode application tries to directly write to an I/O port to control a hardware device, bypassing the OS. What happens?

• A. The write succeeds if the application has been granted administrator privileges by the OS
• B. The write succeeds unless the OS has explicitly blocked that I/O address in software
• C. The CPU raises a hardware exception, transferring control to the kernel — the application cannot execute the instruction regardless of OS software permissions
• D. The write is queued and the OS decides whether to forward it to the hardware

Answer: (C)

Privilege enforcement is hardware-enforced, not software-enforced. When user-mode code tries to execute a privileged instruction (like an I/O write), the CPU itself raises a fault — it does not execute the instruction and instead transfers control to the kernel's exception handler. This happens regardless of any OS-level permissions or administrator status. The key insight is that applications cannot bypass the OS because the hardware physically prevents it, not because the OS promises to catch misbehaving code. Administrator privileges control what the OS will do on your behalf; they do not change the CPU's privilege level for your user-mode process.

Question 2

When an application executes a system call, it provides the system call number and its arguments. Why can't the application also specify which address in the kernel to jump to?

• A. Kernel addresses are encrypted and inaccessible from user mode
• B. The OS validates the jump address before executing it
• C. The hardware forces system call entry through a fixed vector table established at boot time — the application provides arguments but the kernel entry point is determined by the hardware, not the caller
• D. Applications can specify any kernel function, but the OS ignores unauthorized requests

Answer: (C)

This is the critical security property of the system call mechanism. The `syscall` instruction (x86-64) or `svc` instruction (ARM) atomically switches the CPU to kernel mode and jumps to a fixed address stored in a register set up at boot — the application cannot influence this destination. If applications could choose where in the kernel to jump, a malicious program could jump past validation code directly to privileged operations. The fixed entry point ensures every system call goes through proper parameter validation before any privileged work is done.

Question 3

User-mode applications are restricted from directly accessing hardware because the operating system has configured software rules they are expected to follow — a well-behaved application respects these rules, but a malicious one could bypass them.

• T. True
• F. False

Answer: False

User-mode restrictions are enforced by the CPU hardware, not by software rules that applications agree to follow. When user-mode code attempts a privileged instruction, the processor raises a hardware exception before the instruction executes — there is no software check that can be bypassed. This is the entire point of hardware privilege levels: security cannot depend on applications being well-behaved. A malicious application will try to misbehave, and the hardware must make this impossible regardless of the application's intentions.

Question 4

The timer interrupt is essential for a preemptive operating system because it gives the kernel a way to regain control from a running user process even when that process has not voluntarily made a system call.

• T. True
• F. False

Answer: True

Without a timer interrupt, a user process could run forever simply by never making a system call — the OS would have no mechanism to take back the CPU. The hardware timer fires at regular intervals and automatically transfers control to the kernel's interrupt handler (switching to kernel mode), regardless of what the user process is doing. The kernel's scheduler then decides whether to continue the current process or run a different one. This preemption mechanism is what makes modern multitasking possible: no single process can monopolize the CPU indefinitely.

Question 5

Why does the kernel mediate all hardware interactions rather than letting applications interact with hardware directly? What would go wrong without this separation?

Model answer: If applications could access hardware directly, a buggy or malicious application could corrupt memory belonging to other processes, crash the OS, read sensitive data from other applications, or monopolize hardware devices. The kernel mediates all hardware access to enforce isolation between processes (each process sees only its own memory), fairness (the scheduler decides who gets the CPU), and protection (only validated requests reach the hardware). Without this, one application's error or malice could affect every other running process and the entire system.

The OS trust model depends on the kernel being the sole mediator. When process A writes to memory, it can only write to pages the kernel has mapped into its address space. When process A reads a file, the kernel checks permissions before forwarding the request to disk hardware. When process A tries to send a network packet, the kernel validates the operation. Remove this mediation, and the entire security and stability model collapses: applications would need to trust each other completely, and a single exploit or bug anywhere would have system-wide consequences.