linux-kernel - RE: [PATCH v5 4/5] x86/sgx: Implement ENCLS[EUPDATESVN]

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: <DM8PR11MB5750A36D0EC47701322E0683E79FA@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Tue, 20 May 2025 06:36:34 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>, "Hansen, Dave" <dave.hansen@...el.com>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "linux-sgx@...r.kernel.org"
	<linux-sgx@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, "Scarlata,
 Vincent R" <vincent.r.scarlata@...el.com>, "Raynor, Scott"
	<scott.raynor@...el.com>, "Annapurve, Vishal" <vannapurve@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Mallick, Asit
 K" <asit.k.mallick@...el.com>, "Aktas, Erdem" <erdemaktas@...gle.com>, "Cai,
 Chong" <chongc@...gle.com>, "bondarn@...gle.com" <bondarn@...gle.com>,
	"jarkko@...nel.org" <jarkko@...nel.org>, "dionnaglaze@...gle.com"
	<dionnaglaze@...gle.com>
Subject: RE: [PATCH v5 4/5] x86/sgx: Implement ENCLS[EUPDATESVN]

 > >
> > > Why not just fail sgx_open() (e.g., return -EBUSY, or -EAGAIN) in that case?
> > > Userspace can then retry?
> >
> > The idea on the patch was that such a scenario where we run out of entropy
> > should not happen in real life unless RDSEED is under stress (in case we
> > accidentally collided, we do a 10 time retry). So, in this case we keep the
> legacy
> > behaviour, i.e. proceeding without EUPDATESVN. But I can change to the
> above
> > logic to return -EAGAIN in this case if everyone thinks it is a better
> approach.
> 
> Well I think I am seeing conflicting message:
> 
> You mentioned in v4 that some simple (userspace!) tests can make
> EUPDATESVN fail
> "reliably and quite easily even with 10 time retry loop by kernel".  This seems
> to me that "RDSEED is under stress" can certainly happen in in real life.
> 
> Or are you suggesting that kinda "simple tests" cannot happen in real life?

Yes, only under explicit attack. 

> 
> Even we agree that such test cannot happen in real life, since updating SVN is
> about security, I think it's quite fair that we need to consider that the
> platform is under attack.
> 
> Allowing enclave to be created when EUPDATESVN fails due to running out of
> entropy is a clear violation of security to me.  And what's even worse is
> AFAICT
> userspace is not notified about this by any means.

There is no security issues since you can always see the CPU SVN via the
remote attestation process of the given enclave, so you will know for sure
what microcode you run with. And we have this tiny helper in the form of
pr_info() to indicate when kernel finally managed to do the update successfully.
But overall I agree, l will change the logic to return - EAGAIN on entropy issues,
and smth like -EIO on other non-expected errors. 

Best Regards,
Elena.