The §32.7 entropy rationale is the implementer’s guide to building a trustworthy source behind the seed CSR — the analog and statistical discipline the terse normative section assumes.
| Guidance | |
|---|---|
| Over-sample and condition | Each ES16 read is real but imperfect physical entropy. Software gathers many reads (~256 for a 256-bit seed with margin) and hashes them (SHA-2/3) into full-entropy bits before seeding a DRBG. |
| Certify to a standard | The source must meet NIST SP 800-90B or BSI AIS-31 — including the health tests (BIST) surfaced through the OPST state. Certification is a specialist analog/statistical effort, separate from the digital interface. |
| Health monitoring via OPST | BIST signals on-demand self-test; a transient return to BIST from another state is a latched, loggable non-fatal alarm. DEAD is terminal — the source failed and must be reset or replaced. |
| Virtualization | seed is a shared physical resource; a hypervisor should mediate guest access (trap and serve conditioned entropy) to prevent starvation and cross-guest side channels. |
Hardware Designer Notes
For a Linux server, this is what feeds early-boot entropy — the perennial pain point. A certified Zkr source with honest health reporting lets the kernel CSPRNG initialize deterministically at boot instead of blocking on getrandom(). The certification, not the gate count, is the deliverable.
Minimal Linux-boot hart MUST
- Surface health state honestly through OPST (BIST alarms latched until polled, DEAD terminal) — a source that hides failures is worse than none
- Support hypervisor mediation of seed (trappable access) for virtualized deployments
MAY simplify / trap-and-emulate
- Provide more than 16 bits per read via a vendor mechanism, but the standard interface stays 16-bit for portability
- Integrate a hardware conditioner, but software conditioning must still be assumed by portable code
Check yourself — entropy recommendations I
1.The rationale says software must gather many seed reads before using the result. Why can't one ES16 read seed a key directly?
2.How should a hypervisor handle a guest's access to the seed CSR?