[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z--OuMuWx8jUdSU1@kernel.org>
Date: Fri, 4 Apr 2025 10:48:08 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "Annapurve, Vishal" <vannapurve@...gle.com>,
"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>,
"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
"bondarn@...gle.com" <bondarn@...gle.com>,
"Raynor, Scott" <scott.raynor@...el.com>
Subject: Re: [PATCH v2 2/2] x86/sgx: Implement EUPDATESVN and
opportunistically call it during first EPC page alloc
On Fri, Apr 04, 2025 at 06:53:17AM +0000, Reshetova, Elena wrote:
> > On Wed, Apr 02, 2025 at 01:11:25PM +0000, Reshetova, Elena wrote:
> > > > > current SGX kernel code does not handle such errors in any other way
> > > > > than notifying that operation failed for other ENCLS leaves. So, I don't
> > > > > see why ENCLS[EUPDATESVN] should be different from existing
> > behaviour?
> > > >
> > > > While not disagreeing fully (it depends on call site), in some
> > > > situations it is more difficult to take more preventive actions.
> > > >
> > > > This is a situation where we know that there are *zero* EPC pages in
> > > > traffic so it is relatively easy to stop the madness, isn't it?
> > > >
> > > > I guess the best action would be make sgx_alloc_epc_page() return
> > > > consistently -ENOMEM, if the unexpected happens.
> > >
> > > But this would be very misleading imo. We do have memory, even page
> > > allocation might function as normal in EPC, the only thing that is broken
> > > can be EUPDATESVN functionality. Returning -ENOMEM in this case seems
> > > wrong.
> >
> > This makes it not misleading at all:
> >
> > pr_err("EUPDATESVN: unknown error %d\n", ret);
> >
> > Since hardware should never return this, it indicates a kernel bug.
>
> OK, so you propose in this case to print the above message, sgx_updatesvn
> returning an error, and then NULL from __sgx_alloc_epc_page_from_node and
> the __sgx_alloc_epc_page returning -ENOMEM after an iteration over
> a whole set of numa nodes given that we will keep getting the unknown error
> on each node upon trying to do an allocation from each one?
I'd disable ioctl's in this case and return -ENOMEM. It's a cheap sanity
check. Should not ever happen, but if e.g., a new kernel patch breaks
anything, it could help catching issues.
We are talking here about situation that is never expected to happen so I
don't think it is too heavy hammer here. Here it makes sense because not
much effort is required to implement the counter-measures.
>
> Best Regards,
> Elena.
>
>
>
BR, Jarkko
Powered by blists - more mailing lists