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: <510db3c8fbf8a5e2c7687427438ad6110d46cf0a.camel@intel.com>
Date: Tue, 20 May 2025 10:42:57 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Reshetova, Elena" <elena.reshetova@...el.com>, "Hansen, Dave"
	<dave.hansen@...el.com>
CC: "jarkko@...nel.org" <jarkko@...nel.org>, "linux-sgx@...r.kernel.org"
	<linux-sgx@...r.kernel.org>, "Scarlata, Vincent R"
	<vincent.r.scarlata@...el.com>, "x86@...nel.org" <x86@...nel.org>, "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>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "dionnaglaze@...gle.com"
	<dionnaglaze@...gle.com>
Subject: Re: [PATCH v5 4/5] x86/sgx: Implement ENCLS[EUPDATESVN]

On Tue, 2025-05-20 at 06:36 +0000, Reshetova, Elena wrote:
>  > >
> > > > 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. 

Remote attestation can certainly tell the challenger the enclave is still
running on a compromised platform, but I wouldn't say there is *no* security
issues.

E.g., the "crypto assets" that the EUPDATESVN fails to re-generate might have
already been leaked on the compromised platform.  If we allow enclave to run,
the attacker may have chance to steal secrets that aren't remotely provisioned.

You may argue the enclave shouldn't have any secrets before it's verified, but I
think in real world it may not always be the case.