> > 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.
I will try to trim the background text more. Best Regards, Elena.
