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: <DM8PR11MB5750E1B5B13F616BB67AF80CE79FA@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Tue, 20 May 2025 06:46:05 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
CC: "Hansen, Dave" <dave.hansen@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>,
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, "Mallick, Asit K"
	<asit.k.mallick@...el.com>, "Scarlata, Vincent R"
	<vincent.r.scarlata@...el.com>, "Cai, Chong" <chongc@...gle.com>, "Aktas,
 Erdem" <erdemaktas@...gle.com>, "Annapurve, Vishal" <vannapurve@...gle.com>,
	"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>, "bondarn@...gle.com"
	<bondarn@...gle.com>, "Raynor, Scott" <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.

I will try to trim the background text more.

Best Regards,
Elena.