Question bank — Spectre - Meltdown speculative side channels

False. Ye architectural state (registers, committed memory) undo karta hai, lekin microarchitectural footprints chodta hai — sabse important, wo cache lines jo wrong path ne pull in ki thi. Wahi leftover poora attack surface hai.

False. Check present hai aur sahi bhi hai; ye bas late hota hai (retire par), jabki forbidden load pehle hi early out-of-order run ho chuka hota hai aur cache ko touch kar chuka hota hai. Ye ek timing/ordering flaw hai, missing check nahi.

False. Register value tab discard ho jaati hai jab page fault instruction ko abort karta hai. Secret indirectly recover hota hai — measure karke ki secret-indexed probe ne kis cache line ko touch kiya.

False. Meltdown privilege isolation todta hai (user, kernel ko fault ke zariye padhta hai). Spectre victim ke khud ke trusted code ko poisoned predictor ke zariye speculatively misbehave karaata hai — victim ke andar koi privilege violation ki zaroorat nahi hoti.

False. Leaky instructions victim ka legitimate array[x] load hota hai. Attacker sirf ek malicious x deta hai aur branch ko pre-train karta hai, phir victim ka khud ka code misprediction ke under leak karta hai.

Mostly true lekin useless. Agar predictor ko train nahi kiya ja sakta, to attacker reliably wrong-path speculation force nahi kar sakta. Lekin random predictor performance bhi barbad kar deta hai, aur yahi reason hai ki Branch Prediction exist karta hai — to ye koi real option nahi hai.

Aadha sach. Ye wo memory padhta hai jo attacker ke address space mein mapped hai (classically, kernel ka direct-map of all RAM). Agar koi region mapped hi nahi hai, to cache karne ke liye koi entry nahi — isi liye KPTI kaam karta hai.

False. Dono zaroori hain. Speculation hi allow karta hai ki forbidden ya wrong-path load chale; cache side channel woh readout mechanism hai jo rollback ke baad bhi bacha rehta hai. Koi bhi ek hatao aur attack collapse ho jaata hai.

Yahan False — attacker pehle probe array flush karta hai (clflush) taaki baad mein exactly ek hot line clearly dikhe. Clean starting cache attacker ka measuring instrument hai, defense nahi.

if(0) block kabhi commit nahi hota, lekin predictor phir bhi condition resolve hone se pehle usme speculatively enter kar sakta hai. "Architecturally dead" ka matlab "microarchitecturally kabhi execute nahi hua" nahi hota.

Branch prediction fast hai (~1 cycle). Window isliye exist karta hai kyunki condition compute karna (x < array_size) slow hota hai — jaise array_size ek cache miss hai. Fast guess aur slow truth ke beech ki gap hi exploit window hai.

64 B spacing se neighbouring secret values ek hi line par land ho sakti hain (prefetching, adjacent-line effects) aur readout blur ho jaata hai. Tum 4096 B (ek page) space karte ho taaki 256 byte-values mein se har ek clearly distinct line par map ho.

Retpoline prediction ko correct nahi banata — ye indirect jump ko ret mein convert karke BTB ko loop se hata deta hai, aur kisi bhi speculation ko attacker-poisoned target ki jagah ek harmless spin (pause; jmp) ki taraf steer karta hai.

KPTI yeh nahi badalta ki check kab hota hai, balki kya mapped hai ye badalta hai. Ye kernel pages ko user page tables se unmap kar deta hai, to forbidden address ka koi valid translation hi nahi hota speculative load ke liye — secret kabhi cache karne ke liye reachable hi nahi tha.

Unhe sirf matching low address bits chahiye. BTB branch_addr mod 2^n se index karta hai, to 0x1234 aur 0xFF1234 ek hi entry par alias karte hain — yahi collision hai jo attacker training ko victim branch ko poison karne deta hai.

Ye side channel aur performance dono barbad kar deta — ~100× se zyada — kyunki puri cache hierarchy hi 200 ns memory latency hide karne ke liye exist karti hai. Ye koi usable fix nahi hai.

Har possible byte value ko apni distinct cache line/page par spread karne ke liye. Stride ke bina, alag-alag secrets ek hi line mein collide ho jaate aur timing se indistinguishable ho jaate.

Predictors multi-bit history/saturating counters use karte hain, to ek galat call abhi bhi "taken" predict karta hai. Training predictor ko bias karti hai taaki wo single malicious call leaky path par speculate kare.

Meltdown ek single specific ordering bug hai (out-of-order fetch ke baad permission check), to CPUs check ko speculative path mein add kar sakte hain. Spectre speculation in general ko exploit karta hai — CPU ki core optimization strategy — to fix karne ke liye koi single line nahi hai.

Ek core par sibling threads microarchitectural resources (BTB, predictors, kuch caches) share karte hain. Ek attacker thread predictor state poison kar sakta hai ya ek victim thread ki cache timing observe kar sakta hai jo usi core par simultaneously chal raha hota hai.

array1_size par cache miss x < array1_size evaluate karna slow banata hai, speculative window widen hoti hai aur wrong-path load ko zyada time milta hai complete hone ka aur cache footprint chhodne ka.

Register rollback sasta hai (kuch renamed entries). Cache badi hai, shared hai, aur iske contents hi CPU ko fast banate hain — speculation ke liye ise snapshot/restore karna saara performance benefit khatam kar deta aur bahut complexity add kar deta.

Indirect branches (function pointers, virtual calls, returns) instruction mein apna target encode nahi karte, to CPU ko BTB se target guess karna padta hai. Wahi guessed target exactly wahi hai jo attacker poison karta hai; direct branches ka ek fixed encoded target hota hai jisme poison karne ke liye bahut kam hota hai.

Agar koi translation nahi aur hierarchy mein koi data nahi, to speculative load ke paas cache mein laane ke liye kuch nahi — to KPTI-style unmapping (sirf protecting nahi) hi leak ko neuter karti hai.

Tab probe_array[0 * 4096] hot line hogi. 0x00 ek perfectly valid recoverable value hai — lekin attackers kabhi kabhi index 0 ko carefully handle karte hain kyunki prefetchers accidentally pehli line warm kar sakte hain.

Likely noise ya prefetching — ek adjacent-line/stride prefetcher ne neighbour pull in kiya, ya pichle run ka residue raha. Attackers repeat karte hain aur statistical majority lete hain, aur is problem ko suppress karne ke liye unpredictable access order use karte hain.

Speculative window zero ke paas aa jaayegi aur leaky load rollback se pehle kabhi complete nahi ho paayega — koi cache footprint nahi, koi leak nahi. Isi liye attackers actively condition slow karte hain (array_size flush karke) window open rakhne ke liye.

Necessarily nahi. In-order commit normal hai; danger out-of-order data fetch hai permission check se pehle. Agar forbidden fetch permission check se pehle cache reach karta hai, to leak abhi bhi exist karta hai.