Re: [PATCH v5 5/5] x86/sgx: Enable automatic SVN updates for SGX enclaves

[Jarkko Sakkinen <jarkko@kernel.org>]

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