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: <306e06e2aa927719fee9e5cb42cc7657837d2e67.camel@intel.com>
Date: Tue, 22 Apr 2025 21:57:39 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "Hansen, Dave" <dave.hansen@...el.com>, "Reshetova, Elena"
	<elena.reshetova@...el.com>, "Scarlata, Vincent R"
	<vincent.r.scarlata@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Cai, Chong" <chongc@...gle.com>,
	"jarkko@...nel.org" <jarkko@...nel.org>, "Aktas, Erdem"
	<erdemaktas@...gle.com>, "Mallick, Asit K" <asit.k.mallick@...el.com>,
	"bondarn@...gle.com" <bondarn@...gle.com>, "dionnaglaze@...gle.com"
	<dionnaglaze@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "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, 2025-04-22 at 06:54 -0700, Sean Christopherson wrote:
> 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.
> 
> > > It's the hypervisor's responsibility to enumerate SGX_CPUID_EUPDATESVN or not.
> > > E.g. if the kernel is running in a "passthrough" type setup, it would be perfectly
> > > fine to do EUPDATESVN from a guest kernel.  EUPDATESVN could even be proxied,
> > > e.g. by intercepting ECREATE to track EPC usage
> > 
> > I am open to this HYPERVISOR check, because I don't think we currently support
> > any kind of "passthrough" setup?
> 
> Who is "we"?  KVM?  From the SGX driver's perspective, it doesn't know on which
> hypervisor it's running, or the intent of that hypervisor.  I.e. whether or not
> KVM or any other hypervisor supports something is irrelevant.

I was thinking about KVM, but right we cannot assume what will the underneath 
hypervisor do.

> 
> > And depending on what kinda of "passthrough" types, the things that the
> > hypervisor traps can vary.
> > 
> > Anyway, I agree it's not necessary to have this check, because currently it is
> > not possible for a guest to see the EUPDATESVN in CPUID.
> 
> Why is that?
> 

I was thinking about KVM :-( You are right it's up to the hypervisor to decide
whether to advertise EUPDATESVN in CPUID.

Given we don't want to rule out there might be some hypervisor out there which
may just passthrough everything, I agree we should remove this HYPERVISOR check.

Thanks :-)