Summary
The signer's TEE/attested-image planning document (docs/tee-whitelisted-signer-enforcement-plan.md, part of #4007) contains no entropy, RNG, or RDRAND content at all. If confidential-VM or attested-image deployment proceeds, the image measurement needs entropy requirements, because the realistic nonce-repetition vector in a CVM deployment is VM cloning, not any weakness in the signer.
Came out of the #4222 analysis. Filing it so it is not rediscovered later.
The RNG path itself is clean — this is not a bug report
Verified end to end: nonce randomness is getrandom(2) → kernel CSPRNG → a per-operation ChaCha20 expansion whose state is wiped on drop. RDRAND/RDSEED is never a direct userspace source on Linux (the rdrand backend compiles only for SGX and no-OS targets), so the Zen 5 RDSEED erratum (AMD-SB-7055 / CVE-2025-62626, where 16- and 32-bit variants can return zero while signalling success) cannot reach this stack — the kernel issues only the unaffected 64-bit form, and then only as one mixed pool input.
frost-core also already implements the RFC 9591 hedged construction, nonce = H3(random || signing_share), so even hypothetically zeroed OS randomness stays unpredictable to the coordinator. And RNG failure fails closed hard: OsRng panics before any seed becomes an RNG, the FFI boundary converts it to a terminal error, and because the panic fires under the engine mutex the whole engine is poisoned until restart.
What the checklist needs
random.trust_cpu=on — in-TCB RDRAND/RDSEED as a credited early-boot seed (Intel's TDX guest hardening spec requires 256 bits of RDRAND at boot).- virtio-rng uncredited or absent — a host-provided RNG is untrusted in a CVM threat model and must not earn crng-init credit.
CONFIG_VMGENID for snapshot/fork reseed. This is the important one: cloning a VM duplicates kernel CSPRNG state, which is the realistic path to nonce repetition, and CVM deployment makes cloning operationally plausible.- AMD-SB-7055 microcode floor on Zen 5 hosts (belt and braces — the guest path is unaffected by construction).
- seccomp policy permitting
getrandom(2); note that getrandom treats seccomp EPERM as "kernel support absent" and silently falls back to /dev/urandom after polling /dev/random, so the attested image should pin which syscall path is in use.
Explicitly do not
Do not add deterministic nonce derivation. Under ROAST retries — same message, different commitment sets — deterministic nonces convert an RNG problem into share extraction. A safe counter-based variant would need durable counter state, which the frozen markers-only durability spec forbids. The hedged construction already present is the correct answer.
Gating
Only relevant if attested-image or confidential-VM work proceeds. #4222 concluded the TEE direction should be closed as a replacement for the state anchor; #4007 remains additive and decision-gated, and this checklist belongs with it.
Summary
The signer's TEE/attested-image planning document (
docs/tee-whitelisted-signer-enforcement-plan.md, part of #4007) contains no entropy, RNG, or RDRAND content at all. If confidential-VM or attested-image deployment proceeds, the image measurement needs entropy requirements, because the realistic nonce-repetition vector in a CVM deployment is VM cloning, not any weakness in the signer.Came out of the #4222 analysis. Filing it so it is not rediscovered later.
The RNG path itself is clean — this is not a bug report
Verified end to end: nonce randomness is
getrandom(2)→ kernel CSPRNG → a per-operation ChaCha20 expansion whose state is wiped on drop.RDRAND/RDSEEDis never a direct userspace source on Linux (therdrandbackend compiles only for SGX and no-OS targets), so the Zen 5RDSEEDerratum (AMD-SB-7055 / CVE-2025-62626, where 16- and 32-bit variants can return zero while signalling success) cannot reach this stack — the kernel issues only the unaffected 64-bit form, and then only as one mixed pool input.frost-corealso already implements the RFC 9591 hedged construction,nonce = H3(random || signing_share), so even hypothetically zeroed OS randomness stays unpredictable to the coordinator. And RNG failure fails closed hard:OsRngpanics before any seed becomes an RNG, the FFI boundary converts it to a terminal error, and because the panic fires under the engine mutex the whole engine is poisoned until restart.What the checklist needs
random.trust_cpu=on— in-TCBRDRAND/RDSEEDas a credited early-boot seed (Intel's TDX guest hardening spec requires 256 bits ofRDRANDat boot).CONFIG_VMGENIDfor snapshot/fork reseed. This is the important one: cloning a VM duplicates kernel CSPRNG state, which is the realistic path to nonce repetition, and CVM deployment makes cloning operationally plausible.getrandom(2); note thatgetrandomtreats seccompEPERMas "kernel support absent" and silently falls back to/dev/urandomafter polling/dev/random, so the attested image should pin which syscall path is in use.Explicitly do not
Do not add deterministic nonce derivation. Under ROAST retries — same message, different commitment sets — deterministic nonces convert an RNG problem into share extraction. A safe counter-based variant would need durable counter state, which the frozen markers-only durability spec forbids. The hedged construction already present is the correct answer.
Gating
Only relevant if attested-image or confidential-VM work proceeds. #4222 concluded the TEE direction should be closed as a replacement for the state anchor; #4007 remains additive and decision-gated, and this checklist belongs with it.