5.1.13
Intuition Ek hi saansh mein core ideaEk CPU alag-alag trust levels pe code run kar sakta hai. Kuch instructions (machine ko halt karna, memory remap karna, I/O devices ko touch karna) itne dangerous hote hain ki sirf operating system kernel ko hi unhe run karne ki permission hai. Hardware ek bit enforce karta hai jo kehta hai "abhi kaun run kar raha hai" — aur jab jawab hota hai "sirf ek user program" tab privileged operations refuse kar deta hai.
Intuition Pehle naïve view ko steel-man karo"Har program ko sab kuch karne do kyon nahi? Ye mera computer hai!" — Ye sahi lagta hai kyunki apni machine pe aap khud par trust karte ho. Flaw ye hai: ek multi-user, multi-process, networked machine pe, ek buggy ya malicious program ye sab kar sakta hai:
interrupts disable karke poore system ko freeze kar dena,
doosre process ki memory (ya kernel ki) overwrite kar dena,disk seedha read karke secrets chura lena,
timer ko reprogram karke CPU kabhi wapas na dena.
Toh humein ek referee chahiye. Lekin software, software ko referee nahi kar sakta (cheater bas check skip kar sakta hai). Referee hardware khud hona chahiye. Yahi poora reason hai ki privilege levels exist karte hain.
Definition User mode vs Kernel (Supervisor/System) mode
User mode : restricted. Sirf unprivileged (non-privileged) instructions run kar sakta hai aur wohi memory access kar sakta hai jo OS ne uske liye map ki ho. Application code yahan rehta hai.Kernel mode (a.k.a. supervisor / system / privileged mode ): unrestricted. Saare instructions run kar sakta hai jisme privileged instructions bhi shamil hain, memory remap kar sakta hai, devices program kar sakta hai. OS kernel yahan rehta hai.
CPU current level ko ek status register mein store karta hai — conceptually ek mode bit (jaise U/S ya ek Current Privilege Level, CPL ).
Definition Privileged instructionEk instruction jo sirf kernel mode mein legal hai. User mode mein ise attempt karne se hardware ek trap / exception raise karta hai (ek "general protection fault"), execute karne ke bajaye.
Typical privileged instructions: CPU halt karna, interrupts disable/enable karna, page-table base register load karna, direct I/O karna, control registers likhna.
rings (generalisation)
Real CPUs mein aksar do se zyada levels hoti hain jo concentric rings ke roop mein arranged hoti hain. x86 ke paas 4 hain (Ring 0 = kernel, Ring 3 = user; 1 & 2 rarely used). RISC-V ke paas M / S / U (Machine, Supervisor, User) hain. ARM ke paas Exception Levels EL0–EL3 hain. Chhota number = zyada privilege.
Hum required machinery ko step by step goal "user code cheat nahi kar sakta" se derive karte hain.
Step 1 — "Main kaun hoon" store karne ke liye ek jagah chahiye.
Kyon? Check instant hona chahiye, per-instruction. Toh ek hardware status register (PSW / CPSR / mstatus) mein ek bit/field daalo. Ye state hai jo CPU har privileged op pe consult karta hai.
Step 2 — Instruction decoder bit check karta hai.
Kyon? Agar user-mode program ke instruction stream mein ek privileged opcode hai, toh execution fail honi chahiye. Toh decode pe: if (opcode is privileged) and (mode == user): raise trap.
Step 3 — User code bit ko kernel pe set nahi kar sakta.
Kyon? Warna referee ko bypass kiya ja sakta hai. Isliye mode bit likhna khud hi privileged hai . Tum khud ko promote nahi kar sakte. Yahi crucial fixed point hai.
Step 4 — Toh user program OS se help kaise le?
Kyon zaroori? Programs ko legitimately files padhni hain, print karna hai, etc. — ye sab hood ke neeche privileged hain. Solution: ek controlled doorway , ==system call (trap / syscall/ecall)== instruction.
Intuition Bank-teller analogyUser mode = tum lobby mein khade ho. Kernel mode = counter ke peeche vault ke saath. Tum counter ke peeche nahi ja sakte . Tum ek window (syscall) se slip slide kar sakte ho; ek trusted teller (kernel entry code) decide karta hai ise honour karna hai ya nahi. Tum kabhi seedhe vault ko touch nahi karte — aur tum sirf us ek window se enter kar sakte ho, apni pasand ki kisi bhi wall se nahi.
Worked example Example 1 — User program x86 pecli (disable interrupts) try karta hai
User code cli (ek Ring-0 instruction) execute karta hai jabki CPL = 3 hai.
Decode: opcode privileged hai. Yahan check kyon? Enforcement effect se pehle hona chahiye.Compare: required level 0, current level 3 → violation.Result: hardware ek #GP (General Protection Fault) raise karta hai; control kernel ke fault handler pe jump karta hai; OS typically process ko kill kar deta hai SIGSEGV/SIGILL ke saath.Ignore kyon nahi karte? Silent ignore attackers ko probe karne deta; ek trap OS ko control mein rakhta hai.
Worked example Example 2 — Ek legitread() file call
C code read(fd, buf, n):
Library syscall number + args registers mein daalta hai. Registers kyon? Fast, koi memory nahi chahiye, well-defined ABI.
syscall/ecall execute karta hai. Seedhe disk call kyon nahi? Direct I/O privileged hai — user code nahi kar sakta.HW atomically: mode→kernel, PC→syscall entry vector. Vector kyon, arg nahi? Taaki user kernel ke beech mein jump na kar sake.
Kernel fd, buf, n ko validate karta hai (kya buf is process ki memory mein hai?). Validate kyon? Kernel ko apni memory mein likhne ke liye trick nahi kiya jaana chahiye.
Kernel privileged disk read karta hai, data ko buf mein copy karta hai.
sret/iret: mode→user, PC→syscall ke baad wali instruction.
Common mistake "System calls sirf normal function calls hain."Sahi kyon lagta hai: C mein, read() kisi bhi function jaisa dikhta hai. Fix: ek normal call tumhe user mode mein rakhta hai; ek syscall hardware trap ke zariye privilege level change karta hai aur ek kernel-chosen address pe enter karta hai. Cost aur semantics alag hain (mode switch, register save, validation).
Common mistake "Higher ring number = zyada powerful."Sahi kyon lagta hai: bada usually zyada hota hai. Fix: ye inverted hai — Ring 0 sabse zyada privileged hai , Ring 3 (user) sabse kam. Socho "inner ring = core ke kareeb = zyada trusted."
Common mistake "User programs ek critical section banane ke liye interrupts disable kar sakte hain."Sahi kyon lagta hai: kernels bilkul yahi karte hain. Fix: cli/interrupts disable karna privileged hai. User programs ko OS-provided synchronization (mutexes, futexes) use karna chahiye.
Common mistake "Mode bit normal RAM mein stored hai jise program likh sakta hai."Sahi kyon lagta hai: sab kuch kahi na kahi sirf bits hain. Fix: ye ek protected status register mein rehta hai, aur ise likhna khud privileged hai — warna poori scheme collapse ho jaati.
Recall Feynman: ek 12-saal ke bache ko explain karo (click to reveal)Imagine karo computer ek school hai. Bacche (apps) playground mein khel sakte hain (user mode) lekin principal ke office mein nahi ja sakte ya fire alarm touch nahi kar sakte — ye "grown-up only" buttons hain (privileged instructions). Agar koi baccha fire alarm dabane ki koshish kare, toh alarm bajta hai aur ek teacher (OS) unhe pakad leta hai. Agar kisi bacche ko kuch official chahiye (jaise jaldi jaana), toh wo ek khaas window se note pass karta hai (ek system call); teacher decide karta hai haan ya na. Is tarah ek bewakoof baccha poore school ko band nahi kar sakta.
"U CAN'T, but you may ASK."
U ser mode privileged cheez CAN'T touch kar sakta — lekin kernel se ASK kar sakta hai ek s yscall ke zariye.
Aur: "Ring 0 = King." (sabse chhota number rule karta hai).
#flashcards/hardware
Privileged instruction kya hota hai? Ek instruction jo sirf kernel mode mein legal hota hai; user mode mein ise attempt karne se trap/exception raise hota hai.
Privilege levels hardware se enforce kyon hone chahiye, software se nahi? Kyunki software checks us code ke dwara bypass kiye ja sakte hain jo check kiya ja raha hai; sirf hardware har instruction pe unavoidable hai.
User program kernel privilege kaise gain karta hai, sirf safe tarike se? Ek syscall/trap/interrupt ke zariye, jo atomically kernel mode pe switch karta hai AUR ek OS-chosen entry vector pe jump karta hai.
Syscall ko user-supplied address ke bajaye ek fixed OS vector pe kyon jump karna chahiye? Taaki user ye control kare ki kernel run kare , kabhi kahan nahi — kernel mode mein arbitrary code ko run hone se rokne ke liye.
x86 rings mein, kaun sabse zyada privileged hai, Ring 0 ya Ring 3? Ring 0 (kernel); Ring 3 user hai (sabse kam privileged).
"Mode bit likhna" khud ek privileged operation kyon hai? Warna user code khud ko kernel mode mein promote kar sakta tha aur poori protection scheme defeat ho jaati.
OS ek infinite user loop se CPU kaise wapas leta hai? Ek pre-programmed hardware timer interrupt fire karta hai, atomically kernel mein trap karta hua.
Teen typical privileged instructions ke naam batao. CPU halt karna, interrupts disable/enable karna, page-table base register load karna (ya direct I/O).
Jab user code x86 pe ek privileged instruction execute karta hai tab kya hota hai? Hardware ek General Protection Fault (#GP) raise karta hai; OS handler usually process ko terminate kar deta hai.
RISC-V privilege levels, sabse zyada se sabse kam privileged? Machine (M) → Supervisor (S) → User (U).
Interrupts and exceptions — trap mechanism jo mode change karta hai.System calls and the OS interface — controlled doorway.Virtual memory and page tables — remapping privileged hai; per-process isolation enforce karta hai.Pre-emptive multitasking and the scheduler — timer interrupts pe rely karta hai.Processor status register (PSW) — jahan mode bit rehta hai.Instruction encoding and decoding — jahan privilege check hota hai.Protection rings (x86) / Exception Levels (ARM) — multi-level generalisation.
halt disable IRQ I/O page-table
Untrusted programs on shared machine
Hardware referee not software
Kernel supervisor mode unrestricted
Mode bit CPL in status register
Instruction decoder checks bit
Rings x86 EL RISC-V M/S/U
