From: Jarkko Sakkinen <jarkko@kernel.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"Huang, Kai" <kai.huang@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>
Subject: Re: [PATCH v5 4/5] x86/sgx: Implement ENCLS[EUPDATESVN]
Date: Tue, 20 May 2025 22:57:19 +0300 [thread overview]
Message-ID: <aCzen_zuw41a4qAK@kernel.org> (raw)
In-Reply-To: <DM8PR11MB57509295C87F7FB54B773107E79FA@DM8PR11MB5750.namprd11.prod.outlook.com>
On Tue, May 20, 2025 at 06:31:46AM +0000, Reshetova, Elena wrote:
BTW, please keep the line which tells who responded.
> > +/**
> > > + * sgx_updatesvn() - Attempt to call ENCLS[EUPDATESVN]
> > > + * If EPC is empty, this instruction attempts to update CPUSVN to the
> > > + * currently loaded microcode update SVN and generate new
> > > + * cryptographic assets.sgx_updatesvn() Most of the time, there will
> >
> > Is there something wrong here in the text? It looks malformed.
>
> Yes, sorry, looks like copy-paste error I missed in the comment.
> Will fix.
>
> >
> > > + * be no update and that's OK.
> > > + *
> > > + * Return:
> > > + * 0: Success, not supported or run out of entropy
> > > + */
> > > +static int sgx_update_svn(void)
> > > +{
> > > + int ret;
> > > +
> > > + /*
> > > + * If EUPDATESVN is not available, it is ok to
> > > + * silently skip it to comply with legacy behavior.
> > > + */
> > > + if (!X86_FEATURE_SGX_EUPDATESVN)
> > > + return 0;
> > > +
> > > + for (int i = 0; i < RDRAND_RETRY_LOOPS; i++) {
> > > + ret = __eupdatesvn();
> > > +
> > > + /* Stop on success or unexpected errors: */
> > > + if (ret != SGX_INSUFFICIENT_ENTROPY)
> > > + break;
> > > + }
> > > +
> > > + /*
> > > + * SVN either was up-to-date or SVN update failed due
> > > + * to lack of entropy. In both cases, we want to return
> > > + * 0 in order not to break sgx_(vepc_)open. We dont expect
> > > + * SGX_INSUFFICIENT_ENTROPY error unless underlying RDSEED
> > > + * is under heavy pressure.
> > > + */
> > > + if ((ret == SGX_NO_UPDATE) || (ret == SGX_INSUFFICIENT_ENTROPY))
> >
> > if (ret == SGX_NO_UPDATE || ret == SGX_INSUFFICIENT_ENTROPY)
>
> Ok, but I will have to change this anyhow since we seems to trend that we want
> to return -EBUSY when SGX_INSUFFICIENT_ENTROPY and do not
> proceed with open() call.
>
> >
> > > + return 0;
> > > +
> > > + if (!ret) {
> > > + /*
> > > + * SVN successfully updated.
> > > + * Let users know when the update was successful.
> > > + */
> >
> > This comment is like as useless as an inline comment can ever possibly
> > be. Please, remove it.
>
> It is actually not quite so useless because this is the rare case we know
> the EUPDATESVN actually executed and hence the pr_info also below.
> Without this, there will be no way for sysadmin to trace whenever CPU
> SVN was upgraded or not (Sean mentioned that this is already pretty
> opaque to users).
>
> >
> > > + pr_info("SVN updated successfully\n");
> >
> > Let's not add this either in the scope of this patch set.
>
> See above.
>
> >
> > > + return 0;
> > > + }
> >
> > Since you parse error codes already, I don't understand why deal with
> > the success case in the middle of doing that.
> >
> > More consistent would be (not also the use of unlikely()):
> >
> > if (ret == SGX_NO_UPDATE || ret == SGX_INSUFFICIENT_ENTROPY)
> > return 0;
> >
> > /*
> > * EUPDATESVN was called when EPC is empty, all other error
> > * codes are unexpected.
> > */
> > if (unlikely(ret)) {
> > ENCLS_WARN(ret, "EUPDATESVN");
> > return ret;
> > }
> >
> > return 0;
> > }
> >
> > This is how I would rewrite the tail of this function.
>
> I think everyone already re-wrote this function at least once and no one is
> happy with the version from previous person ))
> Let me try another version again, taking into account changes in return codes
> discussed in this thread also.
unlikely() is both (minor) optimization and documents that it is not expected
branch so it obviously makes sense here.
>
> Best Regards,
> Elena.
BR, Jarkko
next prev parent reply other threads:[~2025-05-20 19:57 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 7:24 [PATCH v5 0/5] Enable automatic SVN updates for SGX enclaves Elena Reshetova
2025-05-19 7:24 ` [PATCH v5 1/5] x86/sgx: Introduce a counter to count the sgx_(vepc_)open() Elena Reshetova
2025-05-19 10:47 ` Huang, Kai
2025-05-19 11:35 ` Huang, Kai
2025-05-19 11:43 ` Reshetova, Elena
2025-05-19 11:47 ` Reshetova, Elena
2025-05-19 17:28 ` Jarkko Sakkinen
2025-05-19 22:34 ` Huang, Kai
2025-05-20 6:22 ` Reshetova, Elena
2025-05-19 17:21 ` Jarkko Sakkinen
2025-05-20 6:25 ` Reshetova, Elena
2025-05-20 19:55 ` Jarkko Sakkinen
2025-05-19 7:24 ` [PATCH v5 2/5] x86/cpufeatures: Add X86_FEATURE_SGX_EUPDATESVN feature flag Elena Reshetova
2025-05-19 7:47 ` Ingo Molnar
2025-05-19 11:29 ` Reshetova, Elena
2025-05-19 10:53 ` Huang, Kai
2025-05-19 11:29 ` Reshetova, Elena
2025-05-19 7:24 ` [PATCH v5 3/5] x86/sgx: Define error codes for use by ENCLS[EUPDATESVN] Elena Reshetova
2025-05-19 10:57 ` Huang, Kai
2025-05-19 11:30 ` Reshetova, Elena
2025-05-19 11:36 ` Huang, Kai
2025-05-19 7:24 ` [PATCH v5 4/5] x86/sgx: Implement ENCLS[EUPDATESVN] Elena Reshetova
2025-05-19 11:32 ` Huang, Kai
2025-05-19 11:41 ` Reshetova, Elena
2025-05-19 22:45 ` Huang, Kai
2025-05-20 6:36 ` Reshetova, Elena
2025-05-20 10:42 ` Huang, Kai
2025-05-19 16:02 ` Dave Hansen
2025-05-19 18:24 ` Jarkko Sakkinen
2025-05-20 6:31 ` Reshetova, Elena
2025-05-20 19:57 ` Jarkko Sakkinen [this message]
2025-05-20 20:00 ` Dave Hansen
2025-05-19 7:24 ` [PATCH v5 5/5] x86/sgx: Enable automatic SVN updates for SGX enclaves Elena Reshetova
2025-05-19 8:00 ` Ingo Molnar
2025-05-19 11:27 ` Reshetova, Elena
2025-05-19 12:51 ` Ingo Molnar
2025-05-20 6:43 ` Reshetova, Elena
2025-05-20 7:22 ` Ingo Molnar
2025-05-19 18:32 ` Jarkko Sakkinen
2025-05-20 6:46 ` Reshetova, Elena
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=aCzen_zuw41a4qAK@kernel.org \
--to=jarkko@kernel.org \
--cc=asit.k.mallick@intel.com \
--cc=bondarn@google.com \
--cc=chongc@google.com \
--cc=dave.hansen@intel.com \
--cc=dionnaglaze@google.com \
--cc=elena.reshetova@intel.com \
--cc=erdemaktas@google.com \
--cc=kai.huang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=scott.raynor@intel.com \
--cc=seanjc@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.