linux-kernel - RE: [PATCH v3 2/2] x86/sgx: Implement EUPDATESVN and opportunistically call it during first EPC page alloc

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] [day] [month] [year] [list]

Message-ID: <DM8PR11MB5750200DFF8CF40E3539B688E7832@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Wed, 30 Apr 2025 06:53:32 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, Sean Christopherson
	<seanjc@...gle.com>, "jarkko@...nel.org" <jarkko@...nel.org>
CC: "Huang, Kai" <kai.huang@...el.com>, "linux-sgx@...r.kernel.org"
	<linux-sgx@...r.kernel.org>, "Scarlata, Vincent R"
	<vincent.r.scarlata@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"Annapurve, Vishal" <vannapurve@...gle.com>, "Cai, Chong"
	<chongc@...gle.com>, "Mallick, Asit K" <asit.k.mallick@...el.com>, "Aktas,
 Erdem" <erdemaktas@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "bondarn@...gle.com" <bondarn@...gle.com>,
	"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>, "Raynor, Scott"
	<scott.raynor@...el.com>
Subject: RE: [PATCH v3 2/2] x86/sgx: Implement EUPDATESVN and
 opportunistically call it during first EPC page alloc

> On 4/29/25 04:44, Reshetova, Elena wrote:
> >> On 4/25/25 14:58, Sean Christopherson wrote:
> >>> On Fri, Apr 25, 2025, Dave Hansen wrote:
> >>>> On 4/25/25 14:04, Sean Christopherson wrote:
> >>>>> Userspace is going to be waiting on ->release() no matter what.
> >>>> Unless it isn't even involved and it happens automatically.
> >>> With my Google hat on: no thanks.
> >> I'm completely open to the idea of adding transparency so that folks can
> >> tell when the SVN increments. I'm mostly open to having a new ABI to do
> >> it explicitly in addition to doing it implicitly.]
> > Could you please clarify here Dave what ABI do you have in mind?
> 
> I should have said I'm open to *eventually* adding features and new ABI
> to prod at the SVN state.
> 
> Not now.
> 

OK, so in what direction should I prepare and send a proper v4?
Here are the options as I understand them:

1. Keep the current approach (with all suggested fixes) to execute EUPDATESVN
during first EPC page creation. 

Proc: Single flow inside EPC page allocation. No new uABI. 
Const: Rejecting EPC allocation if EUPDATESVN fails breaks existing behaviour
(note this can be change to original version of the patch where eupdatesvn
failures are ignored and EPC allocation can proceed normally)
More unpredictability to svn change compared to option 2. 

2. Switch to Sean's approach to execute EUPDATESVN during the sgx_open().
Btw, Sean do you agree that we don't gain much doing it second time during
release() given the microcode flow?
I would rather leave only one invocation of eupdatesvn during sgx_inc_usage_count().

Proc: No new uABI. More predictable on svn change compared to option 1.
Cons: Two explicit paths to hook: sgx_open() and sgx_vepc_open(). 

3. explicit uAPI to execute this

Proc: Allows clear explicit, targeted action to execute eupdatesvn, aligned with
instruction definition. 
Cons: deemed not acceptable to create new uABI for this usecase.  

I am personally learning towards option 2 (but without release flow).
Opinions? Sean? Dave? Jarkko? 

Best Regards,
Elena.