5.1.13Instruction Set Architecture (ISA)

System vs user mode and privilege levels

2,256 words10 min readdifficulty · medium1 backlinks

WHY does this exist at all?


WHAT are the modes?

Figure — System vs user mode and privilege levels

HOW does the hardware enforce it? (derive the mechanism)

We derive the required machinery step by step from the goal "user code cannot cheat".

Step 1 — Need a place to store "who am I". Why? The check must be instant, per-instruction. So put a bit/field in a hardware status register (PSW / CPSR / mstatus). This is state the CPU consults on every privileged op.

Step 2 — The instruction decoder checks the bit. Why? If a user-mode program's instruction stream contains a privileged opcode, execution must fail. So on decode: if (opcode is privileged) and (mode == user): raise trap.

Step 3 — User code must NOT be able to just set the bit to kernel. Why? Otherwise the referee is bypassable. Therefore writing the mode bit is itself privileged. You cannot promote yourself. This is the crucial fixed point.

Step 4 — Then how does a user program ever get OS help? Why needed? Programs legitimately need to read files, print, etc. — all privileged under the hood. Solution: a controlled doorway, the ==system call (trap / syscall/ecall)== instruction.


Worked examples


Common mistakes


Recall Feynman: explain to a 12-year-old (click to reveal)

Imagine the computer is a school. Kids (apps) can play in the playground (user mode) but can't go into the principal's office or touch the fire alarm — those are "grown-up only" buttons (privileged instructions). If a kid tries to press the fire alarm, an alarm goes off and a teacher (the OS) grabs them. If a kid needs something official (like leaving early), they hand a note through one special window (a system call); the teacher decides yes or no. This way one silly kid can't shut down the whole school.


Active-recall flashcards

#flashcards/hardware

What is a privileged instruction?
An instruction legal only in kernel mode; attempting it in user mode raises a trap/exception.
Why must privilege levels be enforced by hardware, not software?
Because software checks can be bypassed by the very code being checked; only the hardware is unavoidable on every instruction.
What is the ONLY safe way a user program gains kernel privilege?
Via a syscall/trap/interrupt, which atomically switches to kernel mode AND jumps to an OS-chosen entry vector.
Why must the syscall jump to a fixed OS vector rather than a user-supplied address?
So the user controls that the kernel runs, never where — preventing arbitrary code from running in kernel mode.
In x86 rings, which is most privileged, Ring 0 or Ring 3?
Ring 0 (kernel); Ring 3 is user (least privileged).
Why is "write the mode bit" itself a privileged operation?
Otherwise user code could promote itself to kernel mode and defeat the whole protection scheme.
How does the OS regain the CPU from an infinite user loop?
A pre-programmed hardware timer interrupt fires, atomically trapping into the kernel.
Name three typical privileged instructions.
Halt CPU, disable/enable interrupts, load page-table base register (or direct I/O).
What happens when user code executes a privileged instruction on x86?
Hardware raises a General Protection Fault (#GP); the OS handler usually terminates the process.
RISC-V privilege levels, most to least privileged?
Machine (M) → Supervisor (S) → User (U).

Connections

  • Interrupts and exceptions — the trap mechanism that changes mode.
  • System calls and the OS interface — the controlled doorway.
  • Virtual memory and page tables — remapping is privileged; enforces per-process isolation.
  • Pre-emptive multitasking and the scheduler — relies on timer interrupts.
  • Processor status register (PSW) — where the mode bit lives.
  • Instruction encoding and decoding — where the privilege check happens.
  • Protection rings (x86) / Exception Levels (ARM) — the multi-level generalisation.

Concept Map

motivates

enforced by

defines

defines

hosts

hosts

tells CPU

may run

blocked from

reads

user runs privileged op

halt disable IRQ I/O page-table

generalise

Untrusted programs on shared machine

Privilege levels

Hardware referee not software

User mode restricted

Kernel supervisor mode unrestricted

OS kernel

Application code

Mode bit CPL in status register

Who is running now

Privileged instructions

Instruction decoder checks bit

Raise trap exception

Dangerous operations

Rings x86 EL RISC-V M/S/U

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, CPU ke paas do "trust levels" hote hain: user mode aur kernel mode (jise supervisor ya system mode bhi bolte hain). User mode mein aapke normal apps chalte hain — inko sirf normal (non-privileged) instructions allow hain. Kernel mode mein OS chalta hai, aur yahan saari instructions allowed hain, including khatarnaak wale jaise CPU halt karna, interrupts disable karna, ya memory ki mapping change karna. Ye khatarnaak instructions ko privileged instructions bolte hain, aur agar koi user program inhe chalane ki koshish kare, to hardware turant ek trap/fault raise karta hai aur OS us process ko maar deta hai.

Sabse important baat: ye enforcement hardware karta hai, software nahi. Kyun? Kyunki agar check software mein hota, to cheating karne wala program us check ko skip kar deta. Isliye CPU ke andar ek mode bit hota hai (status register mein), aur decode ke waqt CPU dekhta hai — "abhi kaun chala raha hai?". Aur mast trick ye hai: is mode bit ko change karna bhi privileged hai, matlab user khud ko promote nahi kar sakta. Warna pura system collapse ho jata.

To phir user program OS se kaam kaise karwaye (file read, print, etc.)? Ek hi legal darwaza hai: system call (syscall/ecall/trap). Ye ek atomic hardware transition hai — mode kernel ban jata hai aur PC OS ke fixed entry vector par jump karta hai. User sirf ye decide kar sakta hai ki woh kernel mein enter kare, lekin kahan enter kare ye OS decide karta hai. Isliye attacker apna code kernel mode mein nahi chala sakta.

Ye concept isliye zaroori hai kyunki isi ki wajah se multitasking, security, aur isolation kaam karte hain. Ek timer interrupt (jo bhi privileged hota hai) har thodi der mein CPU ko kernel ko wapas de deta hai, isliye ek infinite loop wala program pure computer ko hang nahi kar sakta. Yaad rakho: "Ring 0 = King" (chhota number = zyada power), aur "User CAN'T, but may ASK."

Go deeper — visual, from zero

Test yourself — Instruction Set Architecture (ISA)

Connections