From: Jarkko Sakkinen <jarkko@kernel.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
"Scarlata, Vincent R" <vincent.r.scarlata@intel.com>,
"Cai, Chong" <chongc@google.com>,
"Aktas, Erdem" <erdemaktas@google.com>,
"Annapurve, Vishal" <vannapurve@google.com>,
"dionnaglaze@google.com" <dionnaglaze@google.com>,
"bondarn@google.com" <bondarn@google.com>,
"Raynor, Scott" <scott.raynor@intel.com>,
"Zhang, Cathy" <cathy.zhang@intel.com>
Subject: Re: [PATCH 4/4] x86/sgx: Implement ENCLS[EUPDATESVN] and opportunistically call it during first EPC page alloc
Date: Thu, 27 Mar 2025 23:19:14 +0200 [thread overview]
Message-ID: <Z-XA0oy_r9VBJPHI@kernel.org> (raw)
In-Reply-To: <DM8PR11MB5750FE25D4C8EC2297952845E7A12@DM8PR11MB5750.namprd11.prod.outlook.com>
On Thu, Mar 27, 2025 at 03:42:30PM +0000, Reshetova, Elena wrote:
> > > > > + case SGX_NO_UPDATE:
> > > > > + pr_debug("EUPDATESVN was successful, but CPUSVN was not
> > > > updated, "
> > > > > + "because current SVN was not newer than
> > > > CPUSVN.\n");
> > > > > + break;
> > > > > + case SGX_EPC_NOT_READY:
> > > > > + pr_debug("EPC is not ready for SVN update.");
> > > > > + break;
> > > > > + case SGX_INSUFFICIENT_ENTROPY:
> > > > > + pr_debug("CPUSVN update is failed due to Insufficient
> > > > entropy in RNG, "
> > > > > + "please try it later.\n");
> > > > > + break;
> > > > > + case SGX_EPC_PAGE_CONFLICT:
> > > > > + pr_debug("CPUSVN update is failed due to concurrency
> > > > violation, please "
> > > > > + "stop running any other ENCLS leaf and try it
> > > > later.\n");
> > > > > + break;
> > > > > + default:
> > > > > + break;
> > > >
> > > > Remove pr_debug() statements.
> > >
> > > This I am not sure it is good idea. I think it would be useful for system
> > > admins to have a way to see that update either happened or not.
> > > It is true that you can find this out by requesting a new SGX attestation
> > > quote (and see if newer SVN is used), but it is not the faster way.
> >
> > Maybe pr_debug() is them wrong level if they are meant for sysadmins?
> >
> > I mean these should not happen in normal behavior like ever? As
> > pr_debug() I don't really grab this.
>
> SGX_NO_UPDATE will absolutely happen normally all the time.
> Since EUPDATESVN is executed every time EPC is empty, this is the
> most common code you will get back (because microcode updates are rare).
> Others yes, that would indicate some error condition.
> So, what is the pr_level that you would suggest?
Right, got it. That changes my conclusions:
So I'd reformulate it like:
switch (ret) {
case 0:
pr_info("EUPDATESVN: success\n);
break;
case SGX_EPC_NOT_READY:
case SGX_INSUFFICIENT_ENTROPY:
case SGX_EPC_PAGE_CONFLICT:
pr_err("EUPDATESVN: error %d\n", ret);
/* TODO: block/teardown driver? */
break;
case SGX_NO_UPDATE:
break;
default:
pr_err("EUPDATESVN: unknown error %d\n", ret);
/* TODO: block/teardown driver? */
break;
}
Since when this is executed EPC usage is zero error cases should block
or teardown SGX driver, presuming that they are because of either
incorrect driver state or spurious error code.
If this happens, we definitely do not want service, right?
I'm not sure of all error codes how serious they are, or are all of them
consequence of incorrectly working driver.
BR, Jarkko
next prev parent reply other threads:[~2025-03-27 21:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 12:34 [PATCH 0/4] Enable automatic SVN updates for SGX enclaves Elena Reshetova
2025-03-21 12:34 ` [PATCH 1/4] x86/sgx: Add total number of EPC pages Elena Reshetova
2025-03-22 21:58 ` Jarkko Sakkinen
2025-03-24 12:12 ` Reshetova, Elena
2025-03-26 19:43 ` Jarkko Sakkinen
2025-03-27 15:29 ` Reshetova, Elena
2025-03-27 21:28 ` Jarkko Sakkinen
2025-03-28 8:07 ` Reshetova, Elena
2025-03-28 8:42 ` Jarkko Sakkinen
2025-03-28 9:11 ` Jarkko Sakkinen
2025-03-28 9:35 ` Reshetova, Elena
2025-03-21 12:34 ` [PATCH 2/4] x86/sgx: Change counter sgx_nr_free_pages -> sgx_nr_used_pages Elena Reshetova
2025-03-22 22:10 ` Jarkko Sakkinen
2025-03-24 12:19 ` Reshetova, Elena
2025-03-26 20:07 ` Jarkko Sakkinen
2025-03-27 15:31 ` Reshetova, Elena
2025-03-27 21:21 ` Jarkko Sakkinen
2025-03-21 12:34 ` [PATCH 3/4] x86/sgx: Define error codes for ENCLS[EUPDATESVN] Elena Reshetova
2025-03-22 21:47 ` Jarkko Sakkinen
2025-03-24 12:21 ` Reshetova, Elena
2025-03-26 20:09 ` Jarkko Sakkinen
2025-03-27 15:38 ` Reshetova, Elena
2025-03-21 12:34 ` [PATCH 4/4] x86/sgx: Implement ENCLS[EUPDATESVN] and opportunistically call it during first EPC page alloc Elena Reshetova
2025-03-22 22:19 ` Jarkko Sakkinen
2025-03-24 12:26 ` Reshetova, Elena
2025-03-26 20:11 ` Jarkko Sakkinen
2025-03-27 15:42 ` Reshetova, Elena
2025-03-27 21:19 ` Jarkko Sakkinen [this message]
2025-03-28 8:27 ` Reshetova, Elena
2025-03-28 8:44 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z-XA0oy_r9VBJPHI@kernel.org \
--to=jarkko@kernel.org \
--cc=asit.k.mallick@intel.com \
--cc=bondarn@google.com \
--cc=cathy.zhang@intel.com \
--cc=chongc@google.com \
--cc=dave.hansen@intel.com \
--cc=dionnaglaze@google.com \
--cc=elena.reshetova@intel.com \
--cc=erdemaktas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=scott.raynor@intel.com \
--cc=vannapurve@google.com \
--cc=vincent.r.scarlata@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox