linux-kernel - Re: [PATCH v6 09/12] x86/sgx: Restructure top-level EPC reclaim function

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: <CYDVWF9BY27K.2MXXROH30QHBT@kernel.org>
Date: Sat, 13 Jan 2024 23:08:27 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Haitao Huang"
 <haitao.huang@...ux.intel.com>, "Mehta, Sohil" <sohil.mehta@...el.com>,
 "x86@...nel.org" <x86@...nel.org>, "dave.hansen@...ux.intel.com"
 <dave.hansen@...ux.intel.com>, "cgroups@...r.kernel.org"
 <cgroups@...r.kernel.org>, "hpa@...or.com" <hpa@...or.com>,
 "mingo@...hat.com" <mingo@...hat.com>, "tj@...nel.org" <tj@...nel.org>,
 "mkoutny@...e.com" <mkoutny@...e.com>, "tglx@...utronix.de"
 <tglx@...utronix.de>, "linux-sgx@...r.kernel.org"
 <linux-sgx@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "bp@...en8.de" <bp@...en8.de>, "Huang, Kai"
 <kai.huang@...el.com>
Cc: "mikko.ylinen@...ux.intel.com" <mikko.ylinen@...ux.intel.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>, "Zhang, Bo" <zhanb@...rosoft.com>,
 "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
 "anakrish@...rosoft.com" <anakrish@...rosoft.com>,
 "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>, "Li,
 Zhiquan1" <zhiquan1.li@...el.com>, "yangjie@...rosoft.com"
 <yangjie@...rosoft.com>
Subject: Re: [PATCH v6 09/12] x86/sgx: Restructure top-level EPC reclaim
 function

On Sat Jan 13, 2024 at 11:04 PM EET, Jarkko Sakkinen wrote:
> On Fri Jan 12, 2024 at 7:07 PM EET, Haitao Huang wrote:
> > On Sun, 17 Dec 2023 19:44:56 -0600, Huang, Kai <kai.huang@...el.com> wrote:
> >
> > >
> > >> >
> > >> > The point is, with or w/o this patch, you can only reclaim 16 EPC  
> > >> pages
> > >> > in one
> > >> > function call (as you have said you are going to remove
> > >> > SGX_NR_TO_SCAN_MAX,
> > >> > which is a cipher to both of us).  The only difference I can see is,
> > >> > with this
> > >> > patch, you can have multiple calls of "isolate" and then call the
> > >> > "do_reclaim"
> > >> > once.
> > >> >
> > >> > But what's the good of having the "isolate" if the "do_reclaim" can  
> > >> only
> > >> > reclaim
> > >> > 16 pages anyway?
> > >> >
> > >> > Back to my last reply, are you afraid of any LRU has less than 16  
> > >> pages
> > >> > to
> > >> > "isolate", therefore you need to loop LRUs of descendants to get 16?
> > >> > Cause I
> > >> > really cannot think of any other reason why you are doing this.
> > >> >
> > >> >
> > >>
> > >> I think I see your point. By capping pages reclaimed per cycle to 16,
> > >> there is not much difference even if those 16 pages are spread in  
> > >> separate
> > >> LRUs . The difference is only significant when we ever raise that cap.  
> > >> To
> > >> preserve the current behavior of ewb loops independent on number of LRUs
> > >> to loop through for each reclaiming cycle, regardless of the exact value
> > >> of the page cap, I would still think current approach in the patch is
> > >> reasonable choice.  What do you think?
> > >
> > > To me I won't bother to do that.  Having less than 16 pages in one LRU is
> > > *extremely rare* that should never happen in practice.  It's pointless  
> > > to make
> > > such code adjustment at this stage.
> > >
> > > Let's focus on enabling functionality first.  When you have some real
> > > performance issue that is related to this, we can come back then.
> > >
> >
> > I have done some rethinking about this and realize this does save quite  
> > some significant work: without breaking out isolation part from  
> > sgx_reclaim_pages(), I can remove the changes to use a list for isolated  
> > pages, and no need to introduce "state" such as RECLAIM_IN_PROGRESS. About  
> > 1/3 of changes for per-cgroup reclamation will be gone.
> >
> > So I think I'll go this route now. The only downside may be performance if  
> > a enclave spreads its pages in different cgroups and even that is minimum  
> > impact as we limit reclamation to 16 pages a time. Let me know if someone  
> > feel strongly we need dealt with that and see some other potential issues  
> > I may have missed.
>
> We could deal with possible performance regression later on (if there
> is need). I mean there should we a workload first that would so that
> sort stimulus...

I.e. no reason to deal with imaginary workload :-) Go ahead and we'll
go through it.

BR, Jarkko