Open hardware ecosystem (OpenRISC, OpenTitan): Question bank

6.5.12 · D5 · Hardware › Advanced & Emerging Architectures › Open hardware ecosystem (OpenRISC, OpenTitan)

Shuru karne se pehle, ek word jis par hum rely karte hain: black box ka matlab hai ek component jo tum use kar sakte ho lekin read nahi kar sakte — tum uske inputs aur outputs dekhte ho lekin uska internal design nahi. "Open" iska ulta hai: tum design source (RTL) khud padh sakte ho.

True or false — justify

Open ISA ka matlab hai us se bana chip bhi open hai.

False. Ek ISA sirf ek specification hoti hai (software–hardware contract, jaise chess ke rules); ek fully proprietary, closed core ek open ISA implement kar sakta hai, isliye ISA-openness kabhi silicon-openness guarantee nahi karta.

Agar OpenTitan ka RTL public hai, to uski secret keys bhi public hain.

False. Sirf design publish hota hai; per-device secret keys fuses mein hoti hain jo manufacture ke waqt burn hoti hain, RTL mein kabhi nahi — yahi "keys secret, design open" wala split hai Kerckhoffs's Principle se.

Security chip ka design publish karna use kam secure banata hai.

False. Attackers waise bhi chips ko reverse-engineer kar lete hain (decap aur electron microscopy se), isliye secrecy se almost kuch nahi milta; publish karne se defenders backdoors ke liye audit kar sakte hain, to transparency ek fire alarm hai jabki obscurity sirf ek speed bump hai.

OpenRISC aur RISC-V same ISA hain do alag naamon se.

False. Yeh do alag, incompatible ISAs hain — OpenRISC/ORBIS pehle aaya (~2000), RISC-V (Berkeley, ~2010) baad mein, aur unki binaries interchangeable nahi hain; OpenTitan actually RISC-V (Ibex) use karta hai, OpenRISC nahi.

Secure boot mein sirf ek hash prove karta hai ki boot image real vendor se aayi.

False. Ek hash sirf integrity prove karta hai (image alter nahi hui) lekin authenticity nahi; ek attacker jo image aur uska stored hash dono swap kar de, use defeat kar deta hai, isliye ek signature zaroori hai jo hash ko vendor-only private key se bind kare.

Har RISC-V phone SoC open hardware hai.

False. Aisa SoC typically sirf ISA layer par open hota hai; uska microarchitecture, RTL aur layout usually proprietary hote hain — openness per-layer hoti hai (ISA / RTL / toolchain), aur zyaadatar commercial parts sirf pehla layer open karte hain.

OpenRISC mein, next instruction ka address current instruction ko decode kiye bina compute ho sakta hai.

True. Kyunki har instruction fixed 32 bits ki hai, fetch unit

P C_{next} = P C + 4

unconditionally set karta hai, isliye next instruction ka start dhundhne ke liye koi decode nahi chahiye (variable-length x86 ke unlike).

Ek Root of Trust trusted ho sakta hai even agar woh ek black box hai, jab tak woh ek bade vendor ka ho.

False. Root of Trust ke upar sab kuch use implicitly trust karta hai, isliye wahan ek hidden backdoor saare higher layers ko invalidate kar deta hai — aur tum ek design mein backdoor ki absence verify nahi kar sakte jo tum padh nahi sakte; auditability hi poora point hai.

Spot the error

"OpenTitan is secure because its circuit design is kept secret from attackers."

Error hai "kept secret" — OpenTitan ka RTL published hai. Uski security fuses mein secret keys aur collision-resistant hashing par depend karti hai, design chupaane par nahi (Kerckhoffs's Principle).

"Since SHA-256 outputs 256 bits, an attacker needs about

2^{256}

tries to forge a colliding boot image."

Error exponent mein hai. Collision-finding birthday bound

\approx 2^{n /2} = 2^{128}

follow karta hai

n = 256

ke liye,

2^{256}

nahi — phir bhi infeasible hai, lekin correct reasoning half the bit-length hai.

"The public key that anchors secure boot is stored in normal rewritable flash so it can be updated."

Error hai "rewritable flash." Anchoring key one-time-programmable fuses mein hoti hai precisely isliye ki attacker use rewrite karke apna trust anchor substitute na kar sake.

"OpenTitan runs the mor1kx core."

Error core name mein hai. OpenTitan ka CPU Ibex hai, ek small RISC-V core; mor1kx OpenRISC ka flagship core hai — bilkul alag ISA family.

"A 6-instruction OpenRISC routine occupies 24 bytes, and one of those instructions could be 2 bytes to save space."

Doosra clause galat hai. OpenRISC fixed-width hai: har instruction exactly 4 bytes ki hai, isliye saari chhe 4 bytes ki hain aur x86 ki tarah koi variable-length shrinking nahi hai;

6 \times 4 = 24

tabhi hold karta hai kyunki width uniform hai.

"Because RISC-V is an open ISA, anyone can fabricate the Ibex core royalty-free."

Error ISA-openness ko RTL-openness ke saath confuse karta hai. Tum Ibex royalty-free fabricate kar sakte ho kyunki Ibex ka RTL open-licensed hai — sirf ISA ki openness tumhe build karne ke liye koi implementation nahi deti.

"Linus's Law (many eyes find bugs) can't apply to hardware because chips are physical."

Error hai "can't apply." Yeh law design source (RTL) par operate karta hai, jo software ki tarah text hai; RTL publish karne se bahut se reviewers fabrication se pehle flaws dhundh sakte hain, isliye principle directly transfer hota hai.

Why questions

Root of Trust ke liye design chupaana doosre chips se zyaada harmful kyun hai?

Kyunki baad mein boot hone wali har cheez RoT par unconditionally trust karti hai, wahan ek undetected backdoor poore system ko compromise kar deta hai, aur tum ek black box mein uske liye audit nahi kar sakte — isliye sabse zyaada trust-bearing part ke liye, transparency ek zaroorat hai, luxury nahi.

Secure boot mein puri trusted image chip ke andar store karne ki jagah signature kyun use karna padta hai?

Har future image store karna impossible hai (woh manufacture ke baad update hoti hain aur fused storage ke liye bahut badi hain), isliye chip sirf ek chhoti vendor public key store karta hai aur har naye image ka signature uske against verify karta hai — trust ek copy mein nahi, balki ek key mein anchored hoti hai.

Fixed instruction width fetch stage ko sasta kyun banata hai?

Jab har instruction same size ki ho, to next wale ka address ek constant addition hai (

P C + 4

), jisme current instruction ka koi decode nahi chahiye; variable-length designs ko ek instruction partly decode karna padta hai sirf yeh jaanne ke liye ki next kahan se shuru hoti hai.

Open hardware ek design ki longevity kyun improve karta hai?

Kyunki RTL freely licensed aur published hai, design tab bhi survive karta hai jab uski originating company band ho jaye — koi bhi use maintain, re-fabricate ya fork karta reh sakta hai, isliye yeh ek vendor ki lifespan se tied nahi hai.

Birthday bound

2^{n /2}

hai na ki

2^{n}

— boot-image collisions ke liye relevant number kyun?

Ek attacker jo koi bhi do images same hash ke saath dhundh raha ho, woh bahut saare trials mein pairwise matches exploit karta hai, isliye expected pehla collision lagbhag

1.18 \cdot 2^{n /2}

candidates par milta hai — ek specific target hash hit karne ke liye zaroorat

2^{n}

se kahin kam.

"Open ISA" kafi kyun nahi hai ek shipping chip ko backdoors ke liye audit karne ke liye?

ISA sirf behaviour specify karta hai (instructions ka matlab kya hai), implementation nahi; ek backdoor microarchitecture/RTL aur layout mein rehta hai, isliye silicon audit karne ke liye tumhare paas RTL aur layout open hona chahiye — sirf spec nahi.

Edge cases

Agar ek hash function ka output sirf 1 bit wide hota, to kya boot-image collision ke liye abhi bhi

2^{n /2}

effort chahiye hoti?

Haan formula ke anusaar (

2^{1/2} \approx 1.4

), matlab ~1–2 tries — jo correctly signal karta hai ki tiny hashes useless hain: security

n

ke bade hone par depend karti hai (256), isliye birthday bound astronomically bada ho jaata hai.

Chain of trust ka kya hota hai agar stage

i

ke signature ka verification fail ho jaaye?

Root of Trust stage

i

ko control hand off karne se mana kar deta hai, isliye boot halt ho jaata hai (ya recovery par fall back karta hai) unverified code chalane ki jagah — chain sirf utni lambi hai jitne last successfully verified link tak.

Kya ek chip toolchain layer par open lekin RTL layer par closed ho sakti hai?

Haan — teen layers independent hain, isliye tumhare paas ek open compiler/simulator ho sakta hai jo ek completely proprietary core ke liye target kare; ek layer ki openness doosri ke baare mein kuch nahi kehti.

Kya ek fully closed chip banana possible hai jo phir bhi standard RISC-V software run kare?

Haan. Kyunki RISC-V sirf ek specification hai, ek vendor use secret RTL aur layout se implement kar sakta hai; software theek chalta hai (ISA contract honor hota hai) jabki silicon ek black box rehti hai.

Kya hoga agar ek attacker fused public key khud ko replace kar de?

Woh properly built device par nahi kar sakte — key one-time-programmable fuses mein hoti hai jo burn hone ke baad physically rewrite nahi ho sakti, isliye trust anchor immutable hai; yahi boundary condition hai jo poori chain ko software par nahi, hardware par rest karati hai.

Agar do alag boot images ka ek hi hash ho (collision exist kare), to kya secure boot swap pakad lega?

Nahi — measurement

m_{i} = H (I_{i})

dono ke liye identical hogi, isliye signature check malicious image ke liye bhi pass ho jaayega; exactly isliye hash ki collision-resistance ek hard requirement hai, nicety nahi.

Recall Jaane se pehle ek-line self-test

Ek open RoT ki security ultimately kahan rehti hai? ::: Secret keys mein jo one-time-programmable fuses mein hain, saath mein collision-resistant hashing aur vendor signatures — published design ki secrecy mein kabhi nahi.