Question bank — System vs user mode and privilege levels

False. A call stays in user mode and jumps to a user-chosen address; a syscall performs a hardware trap that changes the privilege level to kernel and jumps to an OS-chosen entry vector.

False. Ordinary arithmetic, loads, stores, and branches run identically in both modes; only the small set of privileged instructions (halt, disable interrupts, load page-table base, direct I/O) is blocked in user mode.

False. Rings are inverted — Ring 0 is the most privileged and Ring 3 (user) the least. "Inner ring = closer to the core = more trusted."

False. It lives in a protected status register (PSW / RISC-V mstatus), and writing it is itself privileged — otherwise a user could just promote itself and the scheme collapses.

False. On sret/iret (the return-from-trap instructions) the mode drops back to user atomically, so control returns to the instruction right after the syscall with privilege restored.

False. It raises a trap/exception (on x86 a #GP, General Protection Fault); the hardware refuses to run it and jumps to the kernel's fault handler, keeping the OS in control.

False. cli (clear-interrupt-flag / interrupt-masking) is privileged, so user code cannot do it; it must use OS-provided synchronization such as mutexes or futexes.

False. The user chooses that it enters the kernel, never where — the PC is set from a fixed OS vector table, preventing jumps into the middle of the kernel.

False. Software cannot referee software — a cheating program would just skip the check; the referee must be the hardware decoder itself, consulting the mode bit each instruction.

False. They are fused into one atomic, uninterruptible act; if separable, an attacker could interleave and run their own code while already in kernel mode.

Wrong — a syscall is usually slower: it costs a mode switch, register save/restore, and argument validation, none of which a same-mode call incurs.

Wrong — direct disk I/O is privileged, so it cannot appear in user code; read() bottoms out in a syscall/ecall that traps into the kernel to do the actual I/O.

Wrong — polling would itself need the CPU, which the loop is hogging. The OS relies on a hardware timer interrupt it armed earlier (privileged) to forcibly re-enter kernel mode; see Pre-emptive multitasking and the scheduler.

Wrong — the kernel must validate that buf lies inside the caller's own mapped memory; otherwise a malicious user could trick the kernel into writing into kernel memory via the page tables.

Wrong — M/S/U are RISC-V's three levels (Machine most privileged), unrelated to x86's rarely-used Rings 1 and 2; both are just different naming for the same idea of ordered privilege levels.

Wrong — real CPUs encode a multi-bit field (CPL 0–3 on x86, EL0–EL3 on ARM), giving several levels; "mode bit" is just the simplest conceptual model.

Wrong — both are traps: they use the same atomic "mode→kernel, PC→OS vector" machinery. A syscall is a deliberate trap; an exception/interrupt is an involuntary one. See Interrupts and exceptions.

Because if user code could set the bit to "kernel", it would promote itself and bypass every check — the whole enforcement scheme depends on this fixed point being unwritable from user mode.

So a user cannot enter the kernel at an arbitrary point (e.g. past a validation check); the fixed entry vector guarantees kernel code always starts at a trusted, checked prologue.

Because a gap between them is exploitable: if privilege rose first, an attacker could seize the instant before the PC moved to the trusted vector and run their own code while already in kernel mode; fusing them removes any such window.

Because enforcement must precede effect — the CPU must refuse a privileged opcode before its dangerous action happens, so decoding consults the mode bit as it recognises the opcode.

On a multi-user, multi-process, networked machine one buggy or malicious program could freeze the system, read another process's memory, or never yield the CPU — so a hardware referee is needed regardless of who owns the box.

Because it lets the kernel forcibly regain the CPU even from code that never voluntarily yields; since arming and disabling the timer are privileged, user code cannot escape it.

Because the user's request may be malicious or buggy; without checking that pointers and file descriptors are legal for that process, the kernel could be tricked into corrupting its own or another process's memory.

It still traps — being in kernel mode does not make undefined opcodes legal; the trap goes to the exception handler, which for a kernel fault typically panics the whole system.

Conceptually the trap machinery still fires, but the mode is already kernel, so there is no privilege elevation; well-designed kernels avoid issuing user-style syscalls to themselves and call internal routines directly instead.

Because the mode-change and PC-jump are atomic and uninterruptible, no interrupt can wedge itself between them; any pending interrupt is taken cleanly before or after, never mid-transition.

Yes — the moment it wants I/O, memory mapping, or a timer, those operations are privileged under the hood, so it must trap into the kernel via a syscall even if its own instruction stream looks entirely ordinary.

Kernel (supervisor) mode — the interrupt trap sets the mode to kernel exactly like a syscall, so the handler may run privileged instructions to service the device.

The comparison is required-level (0) versus current CPL (3); 3 > 0 means insufficient privilege, so it faults with #GP regardless of whether Rings 1 and 2 are in use.

Modern CPUs add an extra, deeper level below the kernel — x86 calls it VMX-root (informally "Ring −1"), ARM uses EL2, RISC-V adds the H-extension (hypervisor S-mode). The guest OS still thinks it is fully privileged, but the hypervisor traps its most dangerous acts, giving it a referee of its own.

No — the hypervisor virtualises the timer just as the kernel virtualises it for user programs: the guest's cli-style or timer-programming attempts trap down to the hypervisor, which keeps the real hardware under its own control.

The instruction that lowers privilege runs in kernel mode (it is part of the trusted return path); lowering privilege is safe and controlled, whereas raising it is the dangerous direction that only a trap may perform.