On Mon, May 19, 2025 at 10:24:31AM +0300, Elena Reshetova wrote: > SGX enclaves have an attestation mechanism. An enclave might, > for instance, need to attest to its state before it is given > a special decryption key. Since SGX must trust the CPU microcode, > attestation incorporates the microcode versions of all processors > on the system and is affected by microcode updates. This enables > deployment decisions based on the microcode version. > For example, an enclave might be denied a decryption key if it > runs on a system that has old microcode without a specific mitigation. > > Unfortunately, this attestation metric (called CPUSVN) is only a snapshot. > When the kernel first uses SGX (successfully executes any ENCLS instruction), > SGX inspects all CPUs in the system and incorporates a record of their > microcode versions into CPUSVN. CPUSVN is only automatically updated at > reboot. > This means that, although the microcode has been updated, enclaves can never > attest to this fact. Enclaves are stuck attesting to the old version until > a reboot. > > The SGX architecture has an alternative to these reboots: the > ENCLS[EUPDATESVN] > instruction [1]. It allows another snapshot to be taken to update CPUSVN > after a runtime microcode update without a reboot. > > Whenever a microcode update affects SGX, the SGX attestation architecture > assumes that all running enclaves and cryptographic assets (like internal > SGX encryption keys) have been compromised. To mitigate the impact of this > presumed compromise, EUPDATESVN success requires that all SGX memory to be > marked as “unused” and its contents destroyed. This requirement ensures > that no compromised enclave can survive the EUPDATESVN procedure and provides > an opportunity to generate new cryptographic assets. > > Attempt to execute EUPDATESVN on the first open of sgx_(vepc)open(). > If EUPDATESVN fails with any other error code than SGX_INSUFFICIENT_ENTROPY, > this is considered unexpected and the open() returns an error. This > should not happen in practice. On contrary SGX_INSUFFICIENT_ENTROPY might > happen due to a pressure on the system DRNG (RDSEED) and therefore > the open() is not blocked to allow normal enclave operation. > > [1] Runtime Microcode Updates with Intel Software Guard Extensions, > https://cdrdv2.intel.com/v1/dl/getContent/648682
I'd hope, despite having the wealth of information in it, this commit message would a go round or few of editing, and nail the gist of this commit better. Then it would be easier in future review the choices made. BR, Jarkko
