Visual walkthrough — System vs user mode and privilege levels

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

---

Step 1 — Problem: do programs, ek CPU

KYA. CPU bas ek box hai jo memory se instructions padhta hai aur unhe ek ke baad ek execute karta hai. Abhi, kuch bhi ek program ko kuch bhi karne se nahi rokta.

YE YAHAN SE KYUN SHURU KARTE HAIN. Lock banane se pehle, humein clearly dekhna hoga ki hum kya lock kar rahe hain aur kisse. Board pe hum do programs draw karte hain — ek normal app aur operating system kernel (wo trusted master program jo sab kuch manage karta hai). Dono apne instructions ek hi CPU mein feed karte hain.

PICTURE. Left side pe do boxes dekho jo dono arrows point kar rahe hain ek single CPU mein. Kuch instructions (pink mein drawn) dangerous hain: HALT (machine band karo), CLI (interrupts disable karo), "remap memory". Abhi tak kuch bhi distinguish nahi karta ki unhe bhejne ki permission kisko hai.

Poori derivation ka goal, ek baar clearly bola gaya:

$\underset{\text{not trusted}}{\underbrace{\text{user program}}}/⟶\underset{\text{must be blocked}}{\underbrace{\text{privileged instruction}}}$

Slash ka matlab hai "ye arrow forbidden hona chahiye". Neeche sab kuch wahi hardware build karta hai jo us slash ko enforce karta hai.

---

Step 2 — Ek bit invent karo: "abhi kaun run kar raha hai?"

KYA. Hum CPU ke andar state ka ek bit add karte hain, jo ek special status register mein rehta hai (real chips pe Processor status register (PSW) / mstatus / CPSR). Ise mode bit $M$ kaho.

KYUN. Check instant hona chahiye aur har instruction pe hona chahiye, isliye "main kaun hoon" ka jawab slow memory mein nahi reh sakta ya recompute nahi ho sakta — ye ek live hardware bit hona chahiye jo CPU pehle se hold karta hai.

$M=\{\begin{array}{ll}0& \text{kernel mode (trusted, can do anything)}\\ 1& \text{user mode (restricted)}\end{array}$

Equation ko term by term padhte hain:

• $M$ — status register ke andar ka single bit.
• $M=0$ — CPU abhi believe karta hai ki kernel run kar raha hai. Full power.
• $M=1$ — CPU abhi believe karta hai ki ek user program run kar raha hai. Limited.

PICTURE. CPU pe ab ek chhota yellow flag drawn hai — wahi $M$ hai. Jab kernel run karta hai, flag $0$ read karta hai; jab app run karta hai, $1$ read karta hai. Abhi kuch bhi ise check nahi karta; hum bas ise store kar rahe hain.

---

Step 3 — Decoder mein check daalo

KYA. Har instruction decoder se guzarti hai — CPU ka wo part jo ek opcode ke raw bits padhta hai aur figure karta hai iska matlab kya hai (dekho Instruction encoding and decoding). Hum wahan ek rule add karte hain.

YAHAN AUR KAHEEN KYUN NAHI. Enforcement dangerous effect se pehle honi chahiye. Decoder execution se pehle aakhri gate hai, isliye ye natural checkpoint hai. Baad mein check karna bahut der ho jaata — machine pehle se halt ho chuki hoti.

Rule, words mein: agar opcode privileged hai aur mode bit user kehta hai, refuse karo aur trap raise karo.

$\text{if }(\text{opcode}\in \text{Privileged})\wedge (M=1)\Rightarrow \text{trap}$

Term by term:

• $\text{opcode}\in \text{Privileged}$ — ye instruction dangerous list pe hai.
• $\wedge$ — logical AND; dono conditions hold karni chahiye.
• $M=1$ — hum user mode mein hain.
• $\text{trap}$ — instruction abort karo, control kernel ko do (ek exception).

PICTURE. Instruction ko decoder mein flow karte dekho. Ek diamond do sawaal poochta hai; sirf jab dono answers "yes" hain tabhi red TRAP path fire hoti hai. Ek harmless instruction (blue) seedha "execute" tak sail karta hai.

---

Step 4 — Obvious hole band karo: $M$ likhna khud privileged hona chahiye

KYA. Ek clever user program kehta hai: "Theek hai — main pehle $M\leftarrow 0$ set kar lunga, phir apni dangerous instruction run karunga." Humein ye forbid karna hoga.

YE LINCHPIN KYUN HAI. Jo referee ko rishwat di ja sake woh referee nahi hai. Isliye instruction "mode bit likho" khud privileged list pe rakhi jaati hai. Kernel banne ke liye, tumhe pehle se kernel hona chahiye. Ye ek deliberate fixed point hai: user code khud ko promote nahi kar sakta.

$\text{"set }M\leftarrow 0\text{"}\in \text{Privileged}$

Ise padhte hain: mode bit ko kernel pe clear karne ka act khud hi ek dangerous instruction hai, isliye Step 3 ke according ise try karne wala user program bas... trap ho jaata hai. Loophole khud hi band ho jaata hai.

PICTURE. Ek user program ka arrow try karta hai andar pahunchkar yellow flag ko $0$ pe flip karne ki. Ye attempt Step 3 ke same decoder check se takraata hai aur TRAP mein bounce ho jaata hai. Flag $1$ pe hi rehta hai.

---

Step 5 — Lekin users ko OS ki zaroorat hai: ek legal darwaza

KYA. Real programs ko files padhni hain, print karna hai, memory allocate karni hai — sab kuch privileged hai neeche se. Isliye hum exactly ek controlled tarika add karte hain kernel mein enter karne ka: system call instruction (syscall / ecall / int 0x80), wo OS interface.

YE SAFE KYUN HAI CHAHE YE KERNEL MODE MEIN ENTER KARTA HAI. Do guarantees, dono hardware se enforce hoti hain:

$\text{user }(M=1)\underset{\text{one atomic HW step}}{\overset{\text{syscall}}{\to }}\text{kernel }(M=0),PC\leftarrow V_{\text{OS}}$

• $M=1\to M=0$ — haan, tum do kernel ban jaate ho.
• $PC\leftarrow V_{\text{OS}}$ — lekin program counter (next instruction ka address) $V_{\text{OS}}$ pe set hota hai, ek fixed entry vector jo OS ne choose kiya hai, tum ne nahi.
• one atomic HW step — mode-flip aur jump ek single uninterruptible act ke roop mein hote hain.

Toh user choose karta hai ki woh kernel mein kab enter kare — kabhi kahan nahi. Tum ek note window se slide karte ho; tum choose nahi karte ki counter ke peeche kaun se room mein jaoge.

PICTURE. User ka syscall arrow ek narrow slot se ek wall ke upar jaata hai. Doosri side pe ye sirf yellow "OS entry vector" dot pe land karta hai — ye physically wall ke kisi aur jagah land nahi kar sakta.

---

Step 6 — Safely wapas neeche aana

KYA. Jab kernel request serve karna finish karta hai, woh ek return instruction (sret / iret) run karta hai jo user mode mein wapas drop karta hai aur app ko uske syscall ke theek baad resume karta hai.

YE BHI EK ATOMIC ACT KYUN HONA CHAHIYE. Same reasoning mirrored: mode $0\to 1$ aur saved user address par jump saath mein hote hain, taaki koi bheech mein galat privilege pe na chale.

$\text{kernel }(M=0)\underset{\text{sret}/\text{iret}}{\overset{\text{atomic}}{\to }}\text{user }(M=1),PC\leftarrow \text{saved return address}$

• $M=0\to M=1$ — power restricted pe wapas drop ho jaati hai.
• saved return address — original syscall ke baad ki exact instruction, jab hum andar gaye the tab stash ki gayi thi.

PICTURE. Round-trip: app → slot se oopar → kernel privileged kaam karta hai → same slot se neeche wapas → app resume hoti hai. Flag trace karta hai $1\to 0\to 1$.

---

Step 7 — Degenerate case: ek program jo kabhi OS ko call nahi karta

KYA. Socho while(1){} — ek infinite loop jo zero system calls aur zero privileged instructions run karta hai. Steps 1–6 kabhi fire nahi hote. Kya ye CPU ko hamesha ke liye apna banaa leta hai?

YE CASE KYUN MATTER KARTA HAI. Agar jawab "haan" hota, toh ek program machine ko freeze kar sakta tha — bilkul wahi disaster jo parent note mein tha. Fix external hai: ek interrupt jise app refuse nahi kar sakta.

Loop dispatch karne se pehle, kernel ne ek hardware timer program kiya tha (ise arm karna privileged hai — loop ise disarm nahi kar sakta). Jab woh fire karta hai:

$\text{timer fires}\Rightarrow \text{same atomic trap as Step 5}\Rightarrow M=0,PC\leftarrow V_{\text{timer}}$

Loop mid-spin interrupt ho jaata hai; scheduler control wapas paata hai aur doosre process pe switch kar sakta hai.

PICTURE. Endless loop spin karta rehta hai (blue circle). Ek yellow lightning bolt — timer — ise strike karta hai aur same "slot se oopar" transition force karta hai. Loop ise aate nahi dekh sakta aur rok nahi sakta.

---

Step 8 — Generalise: do levels se rings tak

KYA. Humne ek single bit $M$ do values ke saath banaya. Real CPUs ise ek chhote number tak generalise karte hain, Current Privilege Level (CPL), jo concentric rings deta hai.

KYUN. Kuch code (device drivers, hypervisors) "full kernel" aur "plain app" ke beech ki power chahta hai. Bit ki jagah number tumhe unhe order karne deta hai.

$\text{CPL}=0\text{(kernel, most power)}\le \dots \le \text{CPL}=3\text{(user, least power)}$

• Chhota number = zyada privilege (counter-intuitive!).
• x86: rings 0–3. RISC-V: M/S/U. ARM: EL0–EL3.
• Hamara rule generalise hota hai: level $r$ chahne wali instruction trap hoti hai jab bhi $\text{CPL}>r$.

PICTURE. Concentric rings, kernel bullseye pe (ring 0), user outermost ring pe (ring 3). Ek arrow yaad dilata hai: inner = core ke zyada paas = zyada trusted.

---

Ek-picture summary

Sab kuch ek saath: do programs, mode bit $M$, decoder check, sealed self-promotion hole, single syscall doorway apne atomic up/down transitions ke saath, aur timer jo even ek silent loop ko kernel ke paas wapas force karta hai.

Recall Feynman: plain words mein poora walkthrough (click to reveal)

Humne ek dumb CPU se shuru kiya jahan koi bhi program kuch bhi kar sakta tha — machine freeze karna bhi. Step 1: humne instructions ko harmless aur dangerous mein sort kiya. Step 2: humne CPU pe ek single flag glue kiya jo kehta hai "kernel" ya "user" abhi. Step 3: humne instruction decoder ko ek rule sikhaya — agar instruction dangerous hai aur flag user kehta hai, toh brakes maaro (ek trap). Step 4: humne ek cheat dekha — ek program flag khud flip karne ki koshish karta hai — toh humne "flag flip karo" ko dangerous list pe rakha; ab tum khud ko promote nahi kar sakte. Step 5: lekin honest programs ko abhi bhi help chahiye, isliye humne wall mein ek darwaza kaata — syscall — aur aise banaya ki tum sirf ye choose karo ki darwaza knock karna hai ya nahi, kabhi kaun se room mein pahunchoge nahi, aur darwaza ek indivisible motion mein khulta hai taaki koi beech ke gap mein ghus na sake. Step 6: return trip same hi reversed kaam karti hai. Step 7: ek program ke liye jo kabhi knock nahi karta aur kabhi misbehave nahi karta, humne kernel ko ek timer arm karne diya jo program touch nahi kar sakta, taaki use waise bhi wapas kheeench liya jaaye — yahi hai kaise OS hamesha charge mein rehta hai. Step 8: finally, ek flag ek chhote number ban jaata hai taaki hum in-between trust levels (rings) rakh sakein, jahan chhota number, zyada power. Woh single flag, ek decoder rule, aur ek atomic doorway hi har secure operating system ki poori foundation hai.

Recall Quick self-test

User loop timer ko disable karke forever kyun nahi run kar sakti? ::: Interrupts disable karna (cli) privileged hai; user mode mein ise attempt karna trap karta hai, isliye timer fire karta rehta hai. syscall kya change karta hai jo ek normal call nahi karta? ::: Ye privilege level (mode bit) change karta hai ek atomic hardware trap ke zariye aur OS-chosen entry vector par jump karta hai. "Mode bit likho" khud ek privileged instruction kyun hai? ::: Taaki user code khud ko kernel promote na kar sake — ye woh fixed point hai jo poori scheme ko unbypassable banata hai.