System vs user mode and privilege levels: Worked examples

5.1.13 · D3 · Hardware › Instruction Set Architecture (ISA) › System vs user mode and privilege levels

Aapne user mode, kernel mode, aur syscall doorway ka idea parent note mein dekha hai. Yahan hum iska ulta karte hain: hum har tarah ki situation list karte hain jo ek privilege system face kar sakta hai, phir har ek ko end tak work out karte hain. Agar aap in sab ko trace kar sakte hain, toh exam mein mode switching ke baare mein kuch bhi surprise nahi kar sakta.

Scenario matrix

Examples work karne se pehle, hum cases ka poora space lay out karte hain. CPU par har real event neeche ke cells mein se ek hoti hai. Dono axes ko socho — "kaun run kar raha hai?" (current mode) aur "unhone abhi kya attempt kiya?" (the event).

#	Current mode	Event attempted	Legal?	Hardware kya karta hai
A	User	ordinary unprivileged instruction (`add`, `load`)	✅	run karta hai, mode unchanged
B	User	privileged instruction (`cli`, `hlt`, write page-table base)	❌	trap → kernel fault handler
C	User	`syscall` / `ecall` (legal doorway)	✅	atomic promotion → kernel entry vector
D	User	external interrupt fires (timer, disk done)	✅	atomic promotion → interrupt vector
E	User	memory access apne mapped region se bahar	❌	page fault → kernel
F	Kernel	koi bhi instruction, including privileged	✅	run karta hai, mode unchanged
G	Kernel	`sret` / `iret` (return to user)	✅	atomic demotion → user, restore user PC
H	Kernel	mode bit directly likhta hai	✅ (kernel only)	mode changes; user ka yeh attempt = cell B
I	degenerate: mode bit = kernel but PC aaya user ki choice se	—	yahi wo exploit hai jo humein prevent karni hai	vectoring ise impossible banata hai
J	limiting: user loop kabhi yield nahi karta (`while(1){}`)	—	timer (cell D) control wapas laata hai	pre-emption
K	word problem: `read()` from a file	mix of A, C, F, G	✅	full round trip
L	exam twist: nested — interrupt during a syscall	mix of D inside F	✅	privilege already kernel; PC saved twice

Neeche ke examples har letter ko cover karte hain. Har example ke title mein matrix cell bataya gaya hai.

Figure — System vs user mode and privilege levels

Worked examples

Example 1 — Cell A: boring-but-essential legal case

Worked example User program

add r1, r2, r3 run karta hai Ek user process (CPL = 3) ek plain addition execute karta hai.

Forecast: Kya kuch trap hoga? Kya mode change hoga? (Padhne se pehle guess karo.)

Opcode decode karo. Yeh step kyun? Enforcement hamesha decode par hoti hai, effect se pehle, taaki ek illegal op kabhi effect na le.
Pucho: kya yeh opcode privileged hai? add sirf program ke apne registers ko touch karta hai → privileged nahi. Iska kya matlab hai? Mode check sirf privileged ops ke liye consulted hoti hai; unprivileged wale ise skip karte hain.
Execute karo. Registers update hote hain, mode CPL = 3 rehta hai.

Verify: Koi trap raise nahi hua, mode unchanged. Sanity check: agar har instruction trap karti, toh user programs kabhi run hi nahi kar paate — isliye common case free honi chahiye. ✅

Example 2 — Cell B: illegal privileged instruction

Worked example User program x86 par

cli (disable interrupts) execute karta hai Current CPL = 3. cli ke liye CPL = 0 chahiye.

Forecast: Kya interrupts actually disable ho jaayenge? CPU aage kahan jaayega?

cli decode karo. Kyun? Wahi reason — effect se pehle check karo.
Required level lookup karo. cli ko level 0 chahiye. Har opcode ke liye required level kyun store karte hain? Taaki ek uniform comparison rule har privileged instruction ko cover kare.
Compare karo: required 0, current 3. Kyunki 3 > 0, running code required se kam trusted hai → violation. "Greater number = less trust" kyun? Rings inward count hote hain; dekho Protection rings (x86) / Exception Levels (ARM). Ring 0 = King.
#GP (General Protection Fault) raise karo. Control kernel ke fault vector par jump karta hai; OS usually process ko kill kar deta hai. Silently ignore kyun nahi karte? Ignore karne se attacker probe kar sakta hai kya allowed hai; trap OS ko charge mein rakhta hai.

Verify: Interrupts kabhi disable nahi hue — effect fire hi nahi hua kyunki decode ne block kar diya. Comparison 3 ≤ 0 false hai, trap confirm karta hai. ✅

Example 3 — Cell C: legal doorway (`syscall`)

Worked example User process

write() ko syscall ke zariye invoke karta hai C library ne syscall number ek register mein rakha, phir syscall execute kiya.

Forecast: syscall ke baad mode kya hai, aur next PC kisne choose kiya — user ne ya OS ne?

syscall user mode mein execute hota hai. syscall user mode mein kyun allowed hai? Yeh woh ek instruction hai jiska poora purpose ek controlled escalation hai — dekho System calls and the OS interface.
Hardware atomically mode → kernel set karta hai. Atomic kyun? Agar mode-change aur jump alag-alag hote, toh ek attacker beech mein ghus ke apna code kernel ke roop mein run kar sakta (yahi forbidden cell I hai).
PC ← fixed OS entry vector, koi user-supplied address nahi. Vector kyun? Taaki user yeh choose kare ki woh kernel mein enter karta hai, kabhii kahan nahi. Yeh cell-I hole band karta hai.
Kernel arguments validate karta hai, privileged kaam karta hai, phir sret (cell G) mode → user drop kar deta hai.

Verify: Step 3 ke baad, mode = kernel aur PC = OS-chosen vector. Dono guarantees ek saath hold hoti hain → koi escalation exploit nahi. ✅

Example 4 — Cell D + J: limiting case, ek user loop jo kabhi yield nahi karta

Worked example User

while(1){} forever run karta hai — OS CPU wapas kaise leta hai? Process koi syscall nahi karta. Bas spin karta rehta hai.

Forecast: Kya machine hamesha ke liye frozen hai? Agar nahi, toh kya bachata hai?

Dispatch se pehle, kernel ne hardware timer arm kiya. Kernel yeh kar sakta hai lekin user kyun nahi? Timer program karna privileged hai (cell B user ko block kar deta). Dekho Pre-emptive multitasking and the scheduler.
Loop user mode mein spin karta hai (iske saare instructions cell A hain — legal, no yield).
Timer fires → external interrupt (cell D). Hardware atomically: mode → kernel, PC → timer handler vector.
Scheduler run hota hai, kisi doosre process par switch kar sakta hai.

Verify: User ise sirf timer disable karke ya interrupts mask karke rok sakta tha — dono privileged (cell B). Toh yeh nahi ho sakta. Isliye loop ek timer quantum ke baad pre-empt hota hai, hamesha ke liye nahi. Limiting behaviour confirmed: infinite user code bhi CPU monopolise nahi kar sakta. ✅

Example 5 — Cell E: out of bounds memory access

Worked example User code ek aise address par likhta hai jo OS ne uske liye kabhi map nahi kiya

*(int*)0xFFFF0000 = 42; jahan woh address kernel ya kisi doosre process ka hai.

Forecast: Kya write kernel memory mein land hogi? Ise kya rokta hai?

Address page table se translate hota hai. Page table kyun involve hota hai? User addresses virtual hain; mapping decide karti hai ki woh kisi physical page (agar hai toh) tak pahunche.
Is page ka page-table entry "user mode se accessible nahi" mark hai (ya absent hai). Kyun? Kernel ne deliberate apne pages ko user-writable map nahi kiya.
Hardware page fault raise karta hai → kernel handler. OS dekhta hai access illegal tha aur process ko kill kar deta hai.

Verify: Value 42 kabhi kernel memory mein nahi pahuncha — mapping check store complete hone se pehle hua. Kernel mode mein bhi yeh user-mode access bit ke against protect karta hai; mode field aur page permission mil ke kaam karte hain. ✅

Example 6 — Cell H vs I: fixed point, aap khud apne aap ko promote kyun nahi kar sakte

Worked example Malicious user

mov CPL, 0 try karta hai (pretend-instruction: "bas mera mode kernel set karo") Attacker ka idea: doorway skip karo, mode bit directly likho.

Forecast: Kya CPU kernel ban jaayega? Yeh poore design ka crux kyun hai?

Write-to-mode-bit opcode decode karo. Kyun check karo? Mode bit likhna khud ek privileged operation hai (cell H sirf kernel mein legal hai).
Compare karo: required level 0, current 3 → violation → trap (cell B).
Toh ek hi raasta hai jisse mode bit user mode se kernel ban sakta hai, woh hai syscall/interrupt (cells C, D), jo saath hi PC ko ek OS vector par force karta hai (cell I unreachable hai).

Verify: Escalation ke liye mode bit likhna zaroori hai; likhne ke liye pehle se kernel hona zaroori hai. Yeh ek fixed point hai — aap privilege bootstrap nahi kar sakte. Exploit cell I ("kernel mode lekin PC user ne choose kiya") provably unreachable hai. ✅

Example 7 — Cell K: full word-problem round trip, `read()` ek file

Worked example C se

read(fd, buf, n) — har mode transition trace karo Forecast: Start se finish tak mode kitni baar change hoga? (Ek number guess karo.)

Library syscall number + fd, buf, n registers mein pack karti hai (user mode, cell A). Registers kyun? Fast, ABI-defined, koi memory ki zaroorat nahi.
syscall → mode change #1: user → kernel (cell C). PC → OS entry vector.
Kernel validate karta hai ki buf aur buf+n is process ki memory ke andar hain. Validate kyun? Warna user kernel ko trick kar sakta tha apni memory mein likhne ke liye.
Kernel privileged disk read karta hai (cell F, legal kyunki mode = kernel), bytes buf mein copy karta hai.
sret/iret → mode change #2: kernel → user (cell G). PC → syscall ke baad wali instruction.

Verify: Exactly 2 mode changes (ek upar, ek neeche). Dono hardware-atomic hain; user ne kabhi kernel PC choose nahi kiya. Agar aapka forecast 2 tha, toh ✅.

Example 8 — Cell L: exam twist, ek interrupt syscall ke during

Worked example Kernel syscall service karte waqt timer interrupt fire karta hai

Hum already kernel mode mein hain (mid-read()) jab timer fire karta hai.

Forecast: Kya mode change hoga? Is baar kya extra state save karni padegi?

Hum kernel mode mein hain (mode bit = 0). Agले step ke liye yeh kyun matter karta hai? Interrupt phir bhi vector karta hai, lekin koi user→kernel promotion nahi hoti — hum already kernel mein hain.
Interrupt timer handler par vector karta hai; CPU current (kernel) PC save karta hai taaki syscall resume ho sake. Dobara kyun save karo? Ab hamare paas nested return hai: pehle interrupted kernel code par wapas, baad mein user par wapas.
Handler run karta hai, return karta hai; syscall resume hoti hai; eventually sret user par drop karta hai (cell G).

Verify: Mode kernel → kernel jaata hai (koi promotion nahi), aur do saved return points hain (ek interrupt ke liye, ek original syscall ke liye). Example 7 ka single user→kernel aur kernel→user pair unchanged hai; interrupt strictly uske andar nested hai. ✅

Recall Quick self-test (click to reveal)

Kaun sa matrix cell? User program ki hlt instruction ::: Cell B — user mode mein privileged instruction → trap. Kaun sa matrix cell? Spinning CPU par scheduler ka control wapas lena ::: Cell D (timer interrupt), limiting case J ko enable karta hai. Ek complete read() mein kitne mode changes? ::: Exactly 2 — syscall par upar, sret par neeche. Cell I (kernel mode, user-chosen PC) impossible kyun hai? ::: Kyunki promotion sirf vectored syscall/interrupt ke zariye hoti hai, jo ek OS-chosen PC force karta hai; aur mode bit directly likhna khud privileged hai.

Active-recall flashcards

#flashcards/hardware

Scenario matrix mein, cell B mein kya hota hai (user ek privileged instruction run karta hai)?

Hardware effect se pehle ek trap/#GP raise karta hai; control kernel fault handler par jump karta hai.

Ek full read() syscall mein kitne mode transitions hote hain?

Do — syscall par user→kernel, sret/iret par kernel→user.

Ek user ka while(1){} loop machine ko freeze kyun nahi kar sakta?

Kernel ne ek hardware timer arm kiya (privileged); jab yeh fire karta hai, ek interrupt atomically control OS ko wapas karta hai.