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: <DM8PR11MB5750B37305B3B1FAE4F42D3AE7852@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Thu, 24 Apr 2025 08:34:37 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Sean Christopherson <seanjc@...gle.com>, "Huang, Kai"
	<kai.huang@...el.com>
CC: "Hansen, Dave" <dave.hansen@...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>,
	"jarkko@...nel.org" <jarkko@...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 Tue, Apr 22, 2025, Kai Huang wrote:
> > On Fri, 2025-04-18 at 07:55 -0700, Sean Christopherson wrote:
> > > On Tue, Apr 15, 2025, Elena Reshetova wrote:
> > > That said, handling this deep in the bowels of EPC page allocation seems
> > > unnecessary.  The only way for there to be no active EPC pages is if there
> are
> > > no enclaves.  As above, virtual EPC usage is already all but guaranteed to
> hit
> > > false positives, so I don't think there's anything gained by trying to update
> > > the SVN based on EPC allocations.
> > >
> > > So rather than react to EPC allocations, why not hook sgx_open() and
> sgx_vepc_open()?
> >
> > The only thing I don't like about this is we need to hook both of them.
> 
> And having to maintain a separate counter.

Sorry for the delayed response, I was away for easter holidays. 
Thank you very much for your review, Sean!

I see your point about the issues with SGX-enabled VMs. My overall
understanding was that this would have to be up to the userspace to
prepare the system for EUPDATESVN, which *must* include shutting down
all host enclaves, and also migrating the SGX enabled VMs out of this
host or destroying them (likely the former). Is this an unacceptable assumption?
Because I would rather prefer to keep the kernel code clean and simple
and ask userspace to handle this (note: EUPDATESVN is not a common
action, we expect it to be needed only a couple of times per year max). 

If we follow the approach of trying to execute EUPDATESVN via 
sgx_open() and sgx_vepc_open() paths, it adds more complexity to kernel
code and imo it still doesn’t remove the complexity from userspace
 orchestration sw. I.e. userspace still has to get rid of host enclaves and 
SGX enabled VMs (because syncing with VMs owners to make sure their
encalves are destroyed and these VMs are ready for EUDPATESVN seems
like a big organizational complexity and error prone).
So, the only thing this approach would address would be an EPC
pre-allocation done by qemu? Wouldn't it be more reasonable
(here I am purely speculating, I dont know qemu code) to implement
in qemu the code to drop EPC pre-allocation if no VMs with SGX are
running? That would be a good overall policy imo not to waste EPC
space when not needed in practice. 

Best Regards,
Elena.