linux-kernel - Re: [PATCH 2/4] x86/sgx: Change counter sgx_nr_free_pages -> sgx_nr_used

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: <Z-XBaJ3egJDetauP@kernel.org>
Date: Thu, 27 Mar 2025 23:21:44 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "Hansen, Dave" <dave.hansen@...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 2/4] x86/sgx: Change counter sgx_nr_free_pages ->
 sgx_nr_used_pages

On Thu, Mar 27, 2025 at 03:31:31PM +0000, Reshetova, Elena wrote:
> > On Mon, Mar 24, 2025 at 12:19:37PM +0000, Reshetova, Elena wrote:
> > >
> > > > On Fri, Mar 21, 2025 at 02:34:41PM +0200, Elena Reshetova wrote:
> > > > > sgx_nr_free_pages is an atomic that is used to keep track of
> > > > > free EPC pages and detect whenever page reclaiming should start.
> > > > > Since successful execution of ENCLS[EUPDATESVN] requires empty
> > > > > EPC and a fast way of checking for this, change this variable
> > > > > around to indicate number of used pages instead. The subsequent
> > > > > patch that introduces ENCLS[EUPDATESVN] will take use of this change.
> > > >
> > > > s/subsequent patch//
> > >
> > > Ok
> > >
> > > >
> > > > You should rather express how EUPDATESVN trigger will depend on the
> > > > state of sgx_nr_used_pages and sgx_nr_free_pages.
> > >
> > > How about this explanation:
> > >
> > > "By counting the # of used pages instead of #of free pages, it allows the
> > > EPC page allocation path execute without a need to take the lock in all
> > > but a single case when the first page is being allocated in EPC. This is
> > > achieved via a fast check in atomic_long_inc_not_zero."
> > 
> > Yep, whole a lot more sense.
> > 
> > >
> > > Also, if you think that it is hard to interpret the patch 2/4 without 4/4
> > > I can also squeeze them together and then it becomes right away clear
> > > why the change was done.
> > >
> > >
> > > >
> > > > >
> > > > > No functional changes intended.
> > > >
> > > > Not really understanding how I should interpret this sentence.
> > >
> > > Just as usual: this patch itself doesn’t bring any functional changes
> > > to the way as current SGX code works. I only needed this change to
> > > implement patch 4/4 in more lockless way.
> > >
> > > >
> > > > The commit message does not mention sgx_nr_used_pages, and neiher it
> > > > makes a case why implementing the feature based on sgx_nr_free_pages
> > is
> > > > not possible.
> > >
> > > It is possible to implement it, in fact I did exactly this in the beginning
> > instead,
> > > but as mentioned previously this would have resulted in taking a lock for
> > each
> > > case the page is being allocated.
> > 
> > Have you benchmarked this (memory barrier vs putting the whole thing
> > inside spinlock)?
> > 
> > I have doubts that this would even show in margins given how much e.g.,
> > ELDU takes.
> 
> No, I haven’t benchmarked this. The reason to choose this approach
> (vs. the other one I showed in email now) was purely logical - less
> locks and better code.

You need to have hard data to to turn things around like this.
Otherwise, let's not do this.

EPC allocation is always combined with heave-weight opcode so
this really does not serve any purpose.

> 
> Best Regards,
> Elena.

BR, Jarkko