From: Dave Hansen <dave.hansen@intel.com>
To: Elena Reshetova <elena.reshetova@intel.com>
Cc: jarkko@kernel.org, seanjc@google.com, kai.huang@intel.com,
linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, asit.k.mallick@intel.com,
vincent.r.scarlata@intel.com, chongc@google.com,
erdemaktas@google.com, vannapurve@google.com,
dionnaglaze@google.com, bondarn@google.com,
scott.raynor@intel.com
Subject: Re: [PATCH v5 4/5] x86/sgx: Implement ENCLS[EUPDATESVN]
Date: Mon, 19 May 2025 09:02:39 -0700 [thread overview]
Message-ID: <f5f1bfbf-8323-4bc6-aa79-f277c89b60a0@intel.com> (raw)
In-Reply-To: <20250519072603.328429-5-elena.reshetova@intel.com>
On 5/19/25 00:24, Elena Reshetova wrote:
> The SGX attestation architecture assumes a compromise
> of all running enclaves and cryptographic assets
> (like internal SGX encryption keys) whenever a microcode
> update affects SGX. To mitigate the impact of this presumed
> compromise, a new supervisor SGX instruction: ENCLS[EUPDATESVN],
> is introduced to update SGX microcode version and generate
> new cryptographic assets in runtime after SGX microcode update.
>
> EUPDATESVN requires that SGX memory to be marked as "unused"
> before it will succeed. This ensures that no compromised enclave
> can survive the process and provides an opportunity to generate
> new cryptographic assets.
That's really bizarre text wrapping. You might want to have your editor
give it another go.
I also found this pretty hard to read, but a friendly AI chatbot helped
me rewrite it:
All running enclaves and cryptographic assets (such as internal SGX
encryption keys) are assumed to be compromised whenever an SGX-related
microcode update occurs. To mitigate this assumed compromise the new
supervisor SGX instruction ENCLS[EUPDATESVN] can generate fresh
cryptographic assets.
Before executing EUPDATESVN, all SGX memory must be marked as unused.
This requirement ensures that no potentially compromised enclave
survives the update and allows the system to safely regenerate
cryptographic assets.
> @@ -917,6 +918,62 @@ EXPORT_SYMBOL_GPL(sgx_set_attribute);
> /* Counter to count the active SGX users */
> static atomic64_t sgx_usage_count;
>
> +/**
> + * 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
^ What happened here?
> + * be no update and that's OK.
> + *
> + * Return:
> + * 0: Success, not supported or run out of entropy
> + */
Good documentation will help folks know when they might call this. It
sets clear expectations. When is it safe to call? What do I do if it fails?
> +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;
At this point, it's pretty obvious that this code hasn't been tested.
This code would (I think) croak on any SGX users on non-EUPDATESVN
hardware. I'm going to stop reviewing this now. You've gotten quite a
bit of feedback on it and I think I'll wait for v6, which I'm sure will
have a few more correctness passes on it before going out.
> +
> + 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
Remember, no "we's". Use imperative voice.
next prev parent reply other threads:[~2025-05-19 16:04 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 [this message]
2025-05-19 18:24 ` Jarkko Sakkinen
2025-05-20 6:31 ` Reshetova, Elena
2025-05-20 19:57 ` Jarkko Sakkinen
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=f5f1bfbf-8323-4bc6-aa79-f277c89b60a0@intel.com \
--to=dave.hansen@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=bondarn@google.com \
--cc=chongc@google.com \
--cc=dionnaglaze@google.com \
--cc=elena.reshetova@intel.com \
--cc=erdemaktas@google.com \
--cc=jarkko@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®