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

Message-ID: <aApgOqHvsYNd-yht@google.com>
Date: Thu, 24 Apr 2025 10:19:47 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Elena Reshetova <elena.reshetova@...el.com>
Cc: "jarkko@...nel.org" <jarkko@...nel.org>, Kai Huang <kai.huang@...el.com>, 
	Dave Hansen <dave.hansen@...el.com>, 
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>, 
	Vincent R Scarlata <vincent.r.scarlata@...el.com>, "x86@...nel.org" <x86@...nel.org>, 
	Vishal Annapurve <vannapurve@...gle.com>, Chong Cai <chongc@...gle.com>, 
	Asit K Mallick <asit.k.mallick@...el.com>, Erdem Aktas <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>, Scott Raynor <scott.raynor@...el.com>
Subject: Re: [PATCH v3 2/2] x86/sgx: Implement EUPDATESVN and
 opportunistically call it during first EPC page alloc

On Thu, Apr 24, 2025, Elena Reshetova wrote:
> > On Thu, Apr 24, 2025, Elena Reshetova wrote:
> > +void sgx_dec_usage_count(void)
> > +{
> > +	if (atomic_dec_return(&sgx_usage_count))
> > +		return;
> > +
> > +	guard(mutex)(&sgx_svn_lock);
> > +
> > +	if (atomic_read(&sgx_usage_count))
> > +		return;
> > +
> > +	sgx_update_svn();
> 
> Why do we want to try to execute this on release also?  I would think that
> doing this in sgx_inc_usage_count() is enough.

I assume an actual SVN update takes some amount of time?

If that's correct, then doing the work upon destroying the last enclave is desirable,
as it's less likely to introduce delay that negatively affects userspace.  Userspace
generally won't care about a 10us delay when destroying a process, but a 10us delay
to launch an enclave could be quite problematic, e.g. in the TDX use case where
enclaves may be launched on-demand in response to a guest attestation request.

If the update time is tiny, then I agree that hooking release would probably do
more harm than good.