Open hardware ecosystem (OpenRISC, OpenTitan): Worked examples

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

Scenario matrix

Kisi bhi calculation se pehle, har distinct case-class list karte hain jo is topic mein hai. Neeche har worked example us cell ko fill karta hai jis par woh tagged hai.

#	Case class	Ise alag kya banata hai	Example
A	Fixed-width code size (normal)	plain $4 N$ byte count	Ex 1
B	Code size — zero / degenerate	$N = 0$ , ya ek instruction	Ex 2
C	Address ↔ count inversion	last address diya hai, $N$ nikalo	Ex 3
D	Hash security — birthday bound	collision effort $2^{n /2}$	Ex 4
E	Hash — preimage vs collision (kaun sa attack?)	$2^{n}$ vs $2^{n /2}$ , the trap	Ex 5
F	Signature vs hash — authenticity gap	word problem, attacker dono swap karta hai	Ex 6
G	Chain of trust — broken link (limiting/failure case)	ek stage verify fail kare	Ex 7
H	Fuse / OTP — irreversibility edge case	ek bit un-burn nahi kar sakte	Ex 8
I	"Open" layers — exam twist	kaun sa layer actually open hai?	Ex 9

Ek vector angle problem mein chaar quadrants hote hain; is topic mein yeh nau cells hain. Hum sab nau hit karte hain.

Cell A — code size, normal case

Worked example Ex 1 — ek routine ke liye bytes

Ek OpenRISC-style routine mein $N = 10$ fixed-width $32$ -bit instructions hain. Yeh kitne bytes occupy karta hai, aur uske baad pehle free byte ka address kya hai?

Forecast: byte count pehle guess karo, padhne se pehle. (4 ka multiple? 40 se bada ya chhota?)

Har instruction $32$ bits ki hai. Yeh step kyun? Fixed width RISC ka poora point hai — width $w = 32$ bits, aur $1$ byte $= 8$ bits, toh har instruction $w /8 = 32/8 = 4$ bytes ki hoti hai.
Count se multiply karo. Yeh step kyun? $N$ back-to-back instructions bina kisi gap ke (load/store design inhe tight pack karta hai): $Bytes = 4 N = 4 \times 10 = 40$ .
Pehle free byte ka address. Yeh step kyun? Routine address $0$ par start hoti hai aur bytes $0 \dots 39$ fill karti hai, toh next unused address $40 = 0x28$ hai.

Verify: last instruction byte $4 (N - 1) = 36 = 0x24$ par baithi hai; yeh $0x24 \dots 0x27$ occupy karta hai; next free $= 0x28 = 40$ . ✔ Units: bytes. ✔

Cell B — zero aur degenerate cases

Worked example Ex 2 —

$N = 0$ aur $N = 1$ Formula $Bytes = 4 N$ empty routine ke liye kya kehta hai, aur single-instruction routine ke liye? Kya woh answers physically sense banate hain?

Forecast: kya "0 bytes" ek valid answer hai? Kya "4 bytes" sabse chhota non-empty program hai?

$N = 0$ plug karo. Kyun? Degenerate inputs woh jagah hai jahan formulas silently jhooth bolte hain — inhe hamesha test karo. $4 \times 0 = 0$ bytes. Ek empty routine sach mein kuch bhi occupy nahi karti; formula honest hai.
$N = 1$ plug karo. Kyun? Sabse chhota non-empty case. $4 \times 1 = 4$ bytes — ek instruction $0x00 \dots 0x03$ par, next free byte $0x04$ .
$P C_{next}$ ka sanity check. Kyun? Confirm karo ki "no decode needed" claim edge par bhi hold karti hai: single instruction ke baad, $P C_{next} = 0 + 4 = 4$ . Sahi hai.

Verify: $4 N$ linear hai aur origin se pass hoti hai, toh $N = 0 \Rightarrow 0$ aur har extra instruction exactly $4$ add karti hai. Koi off-by-one lurk nahi karta. ✔

Cell C — relation invert karna

Worked example Ex 3 — last address se instruction count nikalna

Ek disassembly mein last instruction address $0x1C$ par dikhta hai. Code $0x00$ par start hota hai. Kitne instructions $N$ hain?

Forecast: $0x1C$ decimal mein 28 hai — toh kya $N = 28/4 = 7$ hai? Savdhaan raho.

Address convert karo. Kyun? Hum cleanly divide karne ke liye decimal mein kaam karte hain: $0x1C = 1 \times 16 + 12 = 28$ .
Instruction $k$ (0-indexed) ka address $4 k$ hai. Yeh step kyun? Instruction $0$ byte $0$ par, instruction $1$ byte $4$ par, ..., instruction $k$ $4 k$ par. Toh $4 k = 28 \Rightarrow k = 7$ .
Index ko count mein badlo. Kyun? Agar last index $7$ hai aur humne index $0$ par start kiya, toh instructions ki total number $N = 7 + 1 = 8$ hai. Off-by-one hi poora trap hai.

Verify: $8$ instructions bytes $0 \dots 31$ occupy karti hain; last wali $4 (8 - 1) = 28 = 0x1C$ par start hoti hai. ✔ Forward aur back agree karte hain.

Cell D — birthday bound, collision case

Figure — Open hardware ecosystem (OpenRISC, OpenTitan)

Worked example Ex 4 — 128-bit hash ke liye collision effort

Secure boot ek hash $H$ use karta hai jo $n = 128$ -bit digests produce karta hai. Ek attacker ko roughly kitne random images try karne padte hain jab tak unme se do collide na karein (same digest)?

Forecast: kya yeh $2^{128}$ ke aas paas hai, ya bahut chhota? Pehle figure mein red curve dekho.

Tool ka naam: birthday bound. Yeh tool kyun, brute force nahi? Hum pooch rahe hain "mere tries mein se koi bhi do kab match karenge", na ki "main ek fixed target se kab match karunga". $k$ random $n$ -bit values mein, expected pehla collision $k \approx 1.18 2^{n}$ par aata hai — yeh collision resistance hai, aur yeh sabse kamzor wall hai, toh attacker idhar aim karta hai.
Exponent simplify karo. Kyun? $2^{n} = 2^{n /2}$ , toh effort $\approx 2^{n /2}$ . $1.18$ constant drop karo — yeh order of magnitude nahi badlata.
$n = 128$ plug karo. $2^{128/2} = 2^{64} \approx 1.8 \times 1 0^{19}$ .

Verify: $2^{64} = 18, 446, 744, 073, 709, 551, 616 \approx 1.8 \times 1 0^{19}$ . Bahut bada hai lekin $2^{128} \approx 3.4 \times 1 0^{38}$ se kaafi neeche — exactly isliye birthday bound attack of choice hai, aur isliye hum hash widths double choose karte hain us security level ke, jo hum chahte hain. ✔

Cell E — preimage vs collision (the trap)

Worked example Ex 5 — kaun sa effort apply hota hai?

Ek attacker ke paas legitimate boot image ka exact digest $m_{i} = H (I_{i})$ pehle se hai aur woh ek alag image $I_{i}^{'}$ chahta hai jisme $H (I_{i}^{'}) = m_{i}$ ho (taki fused check pass ho jaye). $n = 256$ ke liye, kya yeh $2^{128}$ kaam hai ya $2^{256}$ ?

Forecast: Ex 4 se " $2^{n /2} = 2^{128}$ " reuse karne ka temptation hai. Kya yeh yahan sahi hai?

Attack classify karo. Yeh step kyun? Target digest fixed hai (yeh real image ka hash hai). Ek pre-chosen target match karna ek second-preimage attack hai, free-for-all collision nahi. Alag sawaal ⟹ alag wall.
Fixed target ke liye effort. Kyun? Bina birthday shortcut ke, har guess independently target hit karta hai probability $2^{- n}$ se, toh expected tries $\approx 2^{n} = 2^{256}$ .
Ex 4 se contrast karo. Kyun include karein? Collision ( $2^{128}$ ) second-preimage ( $2^{256}$ ) se easier hai kyunki collision mein attacker dono images control karta hai. Ek secure boot design jo exact expected hash pin karta hai woh harder $2^{256}$ problem force karta hai.

Verify: $2^{256} \approx 1.16 \times 1 0^{77}$ vs collision $2^{128} \approx 3.4 \times 1 0^{38}$ — preimage wall astronomically zyada oocha hai. Trap ("bas $2^{n /2}$ reuse karo") galat, attacker ke liye bahut-zyada-optimistic number deta hai. ✔

Cell F — authenticity gap (word problem)

Worked example Ex 6 — hash akela kyun haar jaata hai

Ek vendor firmware ship karta hai aur $m = H (I)$ uske saath normal flash mein store karta hai. Boot par chip $H (I)$ recompute karta hai aur stored $m$ se compare karta hai. Flash write access wala ek attacker apni image $I^{'}$ boot karna chahta hai. Kya woh kar sakta hai, aur fix kya hai?

Forecast: kya collision-resistance yahan bachati hai? Step 1 se pehle yes/no guess karo.

Attacker ka move. Yeh step kyun? Agar $m$ ordinary rewritable flash mein rehta hai, toh attacker dono $I^{'}$ aur $m^{'} = H (I^{'})$ likhta hai. Boot par chip $H (I^{'}) = m^{'}$ recompute karta hai — match! Koi collision ki zaroorat hi nahi.
Missing property diagnose karo. Kyun? Hash integrity prove karta hai ("image corrupt nahi hua") lekin authenticity nahi ("image vendor se aaya"). Integrity ≠ authenticity — yahi gap poori vulnerability hai.
Fix apply karo: ek signature. Yeh tool kyun? Ek digital signature $σ = Sign_{s k} (m)$ sirf vendor ki private key $s k$ se produce ki ja sakti hai. Chip public key $p k$ se verify karta hai jo fuses mein burn hoti hai aur use rewrite nahi kar sakta. Attacker ke paas $I^{'}$ hai aur $m^{'}$ compute kar sakta hai, lekin $s k$ ke bina valid $σ^{'}$ produce nahi kar sakta.

Verify: trace karo — attacker $I^{'}, m^{'}, σ^{'}$ likhta hai; chip $Verify_{p k} (σ^{'}, m^{'})$ run karta hai; $s k$ ke bina yeh false return karta hai, boot halt ho jaata hai. Forgery exactly us layer par ruk jaati hai jo hash-only scheme ne open chhoda tha. ✔ (Yeh Kerckhoffs action mein hai: security key mein, design mein nahi.)

Cell G — ek broken link (limiting/failure case)

Worked example Ex 7 — ek stage verify fail kare

Chain of trust mein stages hain: ROM → bootloader → OS → app. Maan lo bootloader image tamper hua tha toh uski signature fail ho jaati hai. Kya run hota hai, aur kya nahi hota?

Forecast: kya OS phir bhi boot hoga kyunki "ROM theek tha"? Padhne se pehle guess karo.

ROM stage run karta hai. Kyun? ROM immutable root hai; woh hamesha execute hota hai aur uska kaam next stage (bootloader) measure karna hai.
Stage 2 ka verification fail hota hai. Yeh step kyun? $Verify_{p k} (σ_{boot}, H (I_{boot})) = false$ kyunki tamper ne $I_{boot}$ badal diya, toh uska hash ab signed value se match nahi karta. Figure dekho: broken link colored hai — uske upar sab kuch grey hai (kabhi reach nahi hota).
Chain halt ho jaati hai — koi bhi downstream load nahi hota. Kyun? Core rule hai verify-before-execute: control tabhi hand off hota hai jab true mile. Kyunki stage 2 reject ho gayi, OS aur app kabhi load bhi nahi hote, run karna toh door ki baat. Ek akele broken link poori upper chain severed kar deti hai.

Verify: jo execute hua usse gino = $1$ stage (sirf ROM). Jo verify-and-run hua = $0$ later stages. Limiting behaviour ("ek failure ⟹ full stop") designed safe state hai — fail closed, fail open nahi. ✔

Cell H — fuse irreversibility (edge case)

Worked example Ex 8 — tum ek bit un-burn nahi kar sakte

Ek one-time-programmable (eFuse) field $4$ bits ki hai, sab $0$ se start hoti hain. Manufacturing ise $101 1_{2}$ burn karta hai ek key-version number store karne ke liye. Baad mein koi version $010 0_{2}$ chahta hai. Kya yeh chip replace kiye bina possible hai?

Forecast: kya tum ek fuse $1$ se $0$ back rewrite kar sakte ho? Yes/no guess karo.

Physical operation model karo. Yeh step kyun? eFuse burn one-way hai: yeh $0$ ko $1$ mein turn kar sakta hai (fuse blow) lekin kabhi bhi $1$ ko $0$ back nahi. Toh kisi bhi state se tum sirf zyada bits set kar sakte ho, kabhi clear nahi.
Bit-by-bit compare karo. Kyun? Current $1011$ , target $0100$ . Bit 3: $1 \to 0$ — clearing chahiye. Impossible. Bit 2: $0 \to 1$ (theek hai), bit 1: $1 \to 0$ (impossible), bit 0: $1 \to 0$ (impossible).
Conclusion nikalo. Kyun? Kyunki kam se kam ek bit $1 \to 0$ jaana chahiye, target is chip par unreachable hai. Fuse-based version counters exactly isi ko exploit karte hain: ek attacker stored version kabhi roll back nahi kar sakta purani, vulnerable firmware re-enable karne ke liye.

Verify: reachable states $1011$ se exactly woh hain jo $1011$ se bitwise $\geq$ hain (har $1$ ek $1$ rehta hai): $1011, 1111$ . Target $0100$ us set mein nahi hai, kyunki $0100 AND 1011 = 0000 \neq = 1011$ . ✔ Anti-rollback guarantee hold karti hai.

Cell I — kaun sa layer open hai? (exam twist)

Worked example Ex 9 — actually-open layer spot karo

Ek company ek phone ship karti hai jisme RISC-V CPU hai. Woh ISA compliance docs publish karti hai lekin RTL aur physical layout secret aur licensed rakhte hain. Ek student claim karta hai "toh yeh chip open hardware hai." Kya yeh sahi hai?

Forecast: open ISA — kya isse chip open ho jaati hai? Guess karo.

Teeno layers alag karo. Yeh step kyun? Yaad karo openness independently ISA (spec), microarchitecture/RTL (implementation), toolchain par rehti hai. Hamen har ek check karna hai, inhe lump nahi karna.
Har layer check karo. Kyun? ISA = RISC-V = open (yeh ek public spec hai, chess ke rules ki tarah). RTL = secret/licensed = closed. Toolchain = GCC exist karta hai lekin silicon build flow private hai = effectively closed. $3$ mein se sirf $1$ layer open hai.
Verdict. Kyun? "Open hardware" matlab hai ki silicon design (RTL/layout) inspectable aur fabricable ho. Ek open ISA ek contract hai, design nahi; tum ise fully proprietary core mein implement kar sakte ho. Toh claim false hai — yeh ek closed chip hai jo ek open ISA bolti hai.

Verify: OpenTitan se contrast karo, jo teenon layers par open hai (RISC-V ISA + published Ibex RTL + open toolchain). Phone SoC exactly ek par open hai. Alag count ⟹ alag verdict. ✔

Recall Quick self-test

$N = 10$ 32-bit instructions ke liye bytes ::: $40$ bytes (next free $= 0x28$ ). Instructions agar last $0x1C$ par hai ::: $8$ (index $7$ , plus one for 0-indexing). 128-bit hash ke liye collision effort ::: $\approx 2^{64} \approx 1.8 \times 1 0^{19}$ . SHA-256 ke liye second-preimage effort ::: $\approx 2^{256}$ , $2^{128}$ nahi. Hash akela secure boot mein kyun fail karta hai ::: integrity hai lekin authenticity nahi — attacker image aur uska stored hash dono rewrite karta hai. Kya eFuse $1 \to 0$ ja sakta hai ::: Nahi — burns one-way hain; sirf $0 \to 1$ possible hai, anti-rollback deta hai. Kya open ISA ek chip ko open hardware banata hai ::: Nahi — RTL/layout open hona chahiye; ISA sirf ek spec hai.

Parent: Open hardware ecosystem (OpenRISC, OpenTitan) (index 6.5.12)