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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCt5Nx06rItmWcYR@kernel.org>
Date: Mon, 19 May 2025 21:32:23 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Elena Reshetova <elena.reshetova@...el.com>
Cc: dave.hansen@...el.com, seanjc@...gle.com, kai.huang@...el.com,
	linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, asit.k.mallick@...el.com,
	vincent.r.scarlata@...el.com, chongc@...gle.com,
	erdemaktas@...gle.com, vannapurve@...gle.com,
	dionnaglaze@...gle.com, bondarn@...gle.com, scott.raynor@...el.com
Subject: Re: [PATCH v5 5/5] x86/sgx: Enable automatic SVN updates for SGX
 enclaves

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