From: Jarkko Sakkinen <jarkko@kernel.org>
To: Elena Reshetova <elena.reshetova@intel.com>
Cc: dave.hansen@intel.com, seanjc@google.com, kai.huang@intel.com,
mingo@kernel.org, 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 v6 4/5] x86/sgx: Implement ENCLS[EUPDATESVN]
Date: Fri, 23 May 2025 18:57:45 +0300 [thread overview]
Message-ID: <aDCa-U8buhyjIygO@kernel.org> (raw)
In-Reply-To: <20250522092237.7895-5-elena.reshetova@intel.com>
On Thu, May 22, 2025 at 12:21:37PM +0300, Elena Reshetova wrote:
> 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.
>
> Add the method to perform ENCLS[EUPDATESVN].
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> ---
> arch/x86/kernel/cpu/sgx/encls.h | 5 +++
> arch/x86/kernel/cpu/sgx/main.c | 67 +++++++++++++++++++++++++++++++++
> 2 files changed, 72 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/sgx/encls.h b/arch/x86/kernel/cpu/sgx/encls.h
> index 99004b02e2ed..d9160c89a93d 100644
> --- a/arch/x86/kernel/cpu/sgx/encls.h
> +++ b/arch/x86/kernel/cpu/sgx/encls.h
> @@ -233,4 +233,9 @@ static inline int __eaug(struct sgx_pageinfo *pginfo, void *addr)
> return __encls_2(EAUG, pginfo, addr);
> }
>
> +/* Attempt to update CPUSVN at runtime. */
> +static inline int __eupdatesvn(void)
> +{
> + return __encls_ret_1(EUPDATESVN, "");
> +}
> #endif /* _X86_ENCLS_H */
> diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> index a018b01b8736..109d40c89fe8 100644
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -16,6 +16,7 @@
> #include <linux/vmalloc.h>
> #include <asm/msr.h>
> #include <asm/sgx.h>
> +#include <asm/archrandom.h>
> #include "driver.h"
> #include "encl.h"
> #include "encls.h"
> @@ -920,6 +921,72 @@ 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].
> + * This instruction attempts to update CPUSVN to the
> + * currently loaded microcode update SVN and generate new
> + * cryptographic assets. Must be called when EPC is empty.
> + * Most of the time, there will be no update and that's OK.
> + * If the failure is due to SGX_INSUFFICIENT_ENTROPY, the
> + * operation can be safely retried. In other failure cases,
> + * the retry should not be attempted.
> + *
> + * Return:
> + * 0: Success or not supported
> + * -EAGAIN: Can be safely retried, failure is due to lack of
> + * entropy in RNG.
> + * -EIO: Unexpected error, retries are not advisable.
> + */
> +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 (!cpu_feature_enabled(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 was already up-to-date. This is the most
> + * common case.
> + */
> + if (ret == SGX_NO_UPDATE)
> + return 0;
> +
> + /*
> + * SVN update failed due to lack of entropy in DRNG.
> + * Indicate to userspace that it should retry.
> + */
> + if (ret == SGX_INSUFFICIENT_ENTROPY)
> + return -EAGAIN;
> +
> + if (!ret) {
> + /*
> + * SVN successfully updated.
> + * Let users know when the update was successful.
> + */
> + pr_info("SVN updated successfully\n");
> + return 0;
> + }
> +
> + /*
> + * EUPDATESVN was called when EPC is empty, all other error
> + * codes are unexpected.
> + */
> + ENCLS_WARN(ret, "EUPDATESVN");
> + return -EIO;
> +}
Even if unlikely() was not used I still don't agree with the order i.e.,
dealing with the success case in the middle. So I stand with my earlier
suggestion, except unlikely() (since that was a problem for David, not
going to fight over it).
BR, Jarkko
next prev parent reply other threads:[~2025-05-23 15:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-22 9:21 [PATCH v6 0/5] Enable automatic SVN updates for SGX enclaves Elena Reshetova
2025-05-22 9:21 ` [PATCH v6 1/5] x86/sgx: Introduce a counter to count the sgx_(vepc_)open() Elena Reshetova
2025-05-23 15:54 ` Jarkko Sakkinen
2025-05-23 15:58 ` Dave Hansen
2025-05-23 23:45 ` Jarkko Sakkinen
2025-05-26 11:48 ` Reshetova, Elena
2025-05-26 11:45 ` Reshetova, Elena
2025-05-26 23:19 ` Huang, Kai
2025-05-27 8:02 ` Reshetova, Elena
2025-05-22 9:21 ` [PATCH v6 2/5] x86/cpufeatures: Add X86_FEATURE_SGX_EUPDATESVN feature flag Elena Reshetova
2025-05-23 0:18 ` Huang, Kai
2025-05-23 6:35 ` Reshetova, Elena
2025-05-22 9:21 ` [PATCH v6 3/5] x86/sgx: Define error codes for use by ENCLS[EUPDATESVN] Elena Reshetova
2025-05-23 15:56 ` Jarkko Sakkinen
2025-05-22 9:21 ` [PATCH v6 4/5] x86/sgx: Implement ENCLS[EUPDATESVN] Elena Reshetova
2025-05-23 0:08 ` Huang, Kai
2025-05-29 13:41 ` Reshetova, Elena
2025-05-23 15:57 ` Jarkko Sakkinen [this message]
2025-05-23 15:59 ` Jarkko Sakkinen
2025-05-26 11:09 ` Reshetova, Elena
2025-05-22 9:21 ` [PATCH v6 5/5] x86/sgx: Enable automatic SVN updates for SGX enclaves Elena Reshetova
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=aDCa-U8buhyjIygO@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=mingo@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.