Question bank — System vs user mode and privilege levels

False. call user mode mein hi rehta hai aur user-chosen address par jump karta hai; syscall ek hardware trap perform karta hai jo privilege level kernel tak change karta hai aur ek OS-chosen entry vector par jump karta hai.

False. Ordinary arithmetic, loads, stores, aur branches dono modes mein identically chalte hain; sirf privileged instructions ka chhota sa set (halt, disable interrupts, load page-table base, direct I/O) user mode mein block hota hai.

False. Rings ulti hain — Ring 0 sabse zyada privileged hai aur Ring 3 (user) sabse kam. "Inner ring = core ke zyada paas = zyada trusted."

False. Yeh ek protected status register (PSW / RISC-V mstatus) mein rehta hai, aur ise likhna khud privileged hai — warna ek user khud ko promote kar le aur scheme collapse ho jaaye.

False. sret/iret par (return-from-trap instructions) mode wapas user tak atomically drop hota hai, toh control syscall ke baad wali instruction par wapas aata hai privilege restore hone ke saath.

False. Yeh ek trap/exception raise karta hai (x86 par ek #GP, General Protection Fault); hardware use chalane se mana karta hai aur kernel ke fault handler par jump karta hai, OS ko control mein rakhta hai.

False. cli (clear-interrupt-flag / interrupt-masking) privileged hai, isliye user code yeh nahi kar sakta; use OS-provided synchronization jaise mutexes ya futexes use karne padte hain.

False. User choose karta hai ki woh kernel mein enter kare, kabhi kahan nahi — PC ek fixed OS vector table se set hota hai, kernel ke beech mein jumps rokta hai.

False. Software, software ka referee nahi ho sakta — ek cheating program check ko skip kar dega; referee khud hardware decoder hi hona chahiye, jo har instruction par mode bit consult kare.

False. Yeh ek atomic, uninterruptible act mein fuse hote hain; agar alag ho sakte, toh attacker interleave kar sakta aur apna code chala sakta jabki already kernel mode mein ho.

Galat — syscall usually slower hota hai: isme ek mode switch, register save/restore, aur argument validation ka cost lagta hai, jo same-mode call mein nahi hota.

Galat — direct disk I/O privileged hai, isliye yeh user code mein nahi aa sakta; read() ultimately ek syscall/ecall tak pahuncha hai jo actual I/O karne ke liye kernel mein trap karta hai.

Galat — polling ke liye khud CPU chahiye, jise loop jam ke baitha hai. OS ek hardware timer interrupt par rely karta hai jise usne pehle arm kiya tha (privileged) taaki forcibly kernel mode mein re-enter ho sake; dekho Pre-emptive multitasking and the scheduler.

Galat — kernel ko validate karna hota hai ki buf caller ki apni mapped memory ke andar hai; warna ek malicious user kernel ko trick kar sakta hai ki woh page tables ke zariye kernel memory mein write kare.

Galat — M/S/U RISC-V ke teen levels hain (Machine sabse privileged), x86 ke rarely-used Rings 1 aur 2 se unrelated; dono bas ek hi idea ke alag naming hain ordered privilege levels ke.

Galat — real CPUs ek multi-bit field encode karte hain (CPL 0–3 on x86, EL0–EL3 on ARM), kaafi levels dete hain; "mode bit" sirf sabse simple conceptual model hai.

Galat — dono traps hain: dono usi atomic "mode→kernel, PC→OS vector" machinery use karte hain. Ek syscall ek deliberate trap hai; ek exception/interrupt ek involuntary wala hai. Dekho Interrupts and exceptions.

Kyunki agar user code bit ko "kernel" set kar sake, toh woh khud ko promote kar lega aur har check bypass kar dega — poori enforcement scheme is fixed point par depend karti hai ki woh user mode se unwritable hai.

Taaki user kernel mein arbitrary point par enter na kar sake (jaise ek validation check ke baad); fixed entry vector guarantee karta hai ki kernel code hamesha ek trusted, checked prologue par start ho.

Kyunki unke beech gap exploitable hai: agar privilege pehle badhta, toh attacker us pal ko seize kar sakta pehle ki PC trusted vector par move kare aur apna code chala sakta jabki already kernel mode mein ho; unhe fuse karna aisa koi window hata deta hai.

Kyunki enforcement effect se pehle honi chahiye — CPU ko ek privileged opcode refuse karna hota hai uski dangerous action hone se pehle, isliye decoding mode bit consult karta hai jab opcode recognize karta hai.

Ek multi-user, multi-process, networked machine par ek buggy ya malicious program system ko freeze kar sakta hai, doosre process ki memory read kar sakta hai, ya kabhi CPU yield nahi kar sakta — isliye hardware referee ki zaroorat hai chahe box ka owner koi bhi ho.

Kyunki yeh kernel ko forcibly CPU wapas dilata hai un code se bhi jo kabhi voluntarily yield nahi karta; kyunki timer arm aur disable karna privileged hai, user code isse escape nahi kar sakta.

Kyunki user ki request malicious ya buggy ho sakti hai; bina yeh check kiye ki pointers aur file descriptors us process ke liye legal hain, kernel ko trick kiya ja sakta hai ki woh apni ya doosre process ki memory corrupt kare.

Woh phir bhi trap karega — kernel mode mein hona undefined opcodes ko legal nahi banata; trap exception handler ko jaata hai, aur kernel fault ke liye yeh typically poore system ko panic kar deta hai.

Conceptually trap machinery phir bhi fire hogi, lekin mode already kernel hai, isliye koi privilege elevation nahi hogi; acchi tarah se designed kernels khud user-style syscalls issue karne se bachte hain aur seedhe internal routines call karte hain.

Kyunki mode-change aur PC-jump atomic aur uninterruptible hain, koi interrupt khud ko unke beech mein nahi daal sakta; koi bhi pending interrupt cleanly pehle ya baad mein liya jaata hai, kabhi mid-transition nahi.

Haan — jis pal woh I/O, memory mapping, ya timer chahega, woh operations andar se privileged hain, isliye use syscall ke zariye kernel mein trap karna hoga chahe uska apna instruction stream bilkul ordinary dikhe.

Kernel (supervisor) mode mein — interrupt trap mode ko kernel tak exactly syscall ki tarah set karta hai, isliye handler privileged instructions run kar sakta hai device service karne ke liye.

Comparison required-level (0) versus current CPL (3) hai; 3 > 0 matlab insufficient privilege, isliye yeh #GP se fault karta hai chahe Rings 1 aur 2 use mein hoon ya nahi.

Modern CPUs ek extra, deeper level add karte hain kernel ke neeche — x86 ise VMX-root kehta hai (informally "Ring −1"), ARM EL2 use karta hai, RISC-V H-extension (hypervisor S-mode) add karta hai. Guest OS phir bhi sochta hai ki woh fully privileged hai, lekin hypervisor uske sabse dangerous acts trap karta hai, use apna ek referee deta hai.

Nahi — hypervisor timer ko exactly waise virtualize karta hai jaise kernel user programs ke liye karta hai: guest ke cli-style ya timer-programming attempts hypervisor tak trap ho jaate hain, jo real hardware ko apne control mein rakhta hai.

Woh instruction jo privilege lower karta hai kernel mode mein chalta hai (yeh trusted return path ka hissa hai); privilege lower karna safe aur controlled hai, jabki use raise karna dangerous direction hai jo sirf ek trap hi perform kar sakta hai.