From: Cathy Zhang <[email protected]>
To: [email protected], [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: [RFC PATCH v2 00/10] Support microcode updates affecting SGX
Date: Tue, 15 Mar 2022 09:02:50 +0800 [thread overview]
Message-ID: <[email protected]> (raw)
v1:
https://lore.kernel.org/all/[email protected]/T/
Changes since v1:
- Remove the sysfs file svnupdate. (Thomas Gleixner, Dave Hansen)
- Let late microcode load path call ENCLS[EUPDATESVN] procedure
directly. (Borislav Petkov)
- Update cover letter by removing saying that "...triggered by
administrators via sysfs...".
- Drop the patch for documentation change.
cover letter:
== General Microcode Background ==
Historically, microcode updates are applied by the BIOS or early in
boot. In recent years, several trends have made these old approaches
less palatable.
First, the cadence of microcode updates has increased to deliver
security mitigations. Second, the value of those updates has increased,
meaning that any delay in applying them is unacceptable. Third, users
have become accustomed to approaches like hot patching their kernels
and have a growing aversion to reboots in general.
Users want microcode updates to behave more like a hot patching a
kernel and less like a BIOS update.
== SGX Attestation Background ==
SGX enclaves have an attestation mechanism. An enclave might, for
instance, need to attest to its state before it is given a special
decryption key. Since SGX must trust the CPU microcode, attestation
incorporates the microcode versions of all processors on the system
and is affected by microcode updates. This allows the entity to which
the enclave is attesting to make deployment decisions based on the
microcode version. For example, an enclave might be denied a decryption
key if it runs on a system that has old microcode without a specific
mitigation.
Unfortunately, this attestation metric (called CPUSVN) is only a
snapshot. When the kernel first uses SGX (successfully executes any
ENCLS instruction), SGX inspects all CPUs in the system and incorporates
a record of their microcode versions into CPUSVN. Today, that value is
locked and is not updated until a reboot.
== Problems ==
This means that, although the microcode may be update, enclaves can
never attest to this fact. Enclaves are stuck attesting to the old
version until a reboot.
Old enclaves created before the microcode update are presumed to be
compromised must not be allowed to attest with the new microcode
version.
== Solution ==
EUPDATESVN is a new SGX instruction which allows enclave attestation
to include information about updated microcode without a reboot.
Whenever a microcode update affects SGX, the SGX attestation
architecture assumes that all running enclaves and cryptographic
assets (like internal SGX encryption keys) have been compromised.
To mitigate the impact of this presumed compromise, EUPDATESVN success
requires that all SGX memory to be marked as "unused" and its contents
destroyed. This requirement ensures that no compromised enclave can
survive the EUPDATESVN procedure and provides an opportunity to
generate new cryptographic assets.
This series implements the infrastructure needed to track and tear
down bare-metal enclaves and then run EUPDATESVN, it will be called
by the late microcode load path after the microcode update.
This is a very slow operation. It is, of course, exceedingly disruptive
to enclaves but should be infrequent as microcode updates are released
on the order of every few months. Also, this is not the first piece of
the SGX architecture which will destroy all enclave contents.
A follow-on series will add Virtual EPC (KVM guest) support.
SGX Seamless should handle most SGX flows while doing SVN update, so, this
RFC series is based on SGX EDMM v2 which introduces SGX2 flows.
https://lore.kernel.org/lkml/[email protected]/T/
Here is the spec for your reference:
https://cdrdv2.intel.com/v1/dl/getContent/648682?explicitVersion=true
Cathy Zhang (10):
x86/sgx: Introduce mechanism to prevent new initializations of EPC
pages
x86/sgx: Provide VA page non-NULL owner
x86/sgx: Save enclave pointer for VA page
x86/sgx: Keep record for SGX VA and Guest page type
x86/sgx: Save the size of each EPC section
x86/sgx: Forced EPC page zapping for EUPDATESVN
x86/sgx: Define error codes for ENCLS[EUPDATESVN]
x86/sgx: Implement ENCLS[EUPDATESVN]
x86/cpu: Call ENCLS[EUPDATESVN] procedure in microcode update
x86/sgx: Call ENCLS[EUPDATESVN] during SGX initialization
arch/x86/include/asm/microcode.h | 5 +
arch/x86/include/asm/sgx.h | 46 +++-
arch/x86/kernel/cpu/sgx/encl.h | 3 +-
arch/x86/kernel/cpu/sgx/encls.h | 16 ++
arch/x86/kernel/cpu/sgx/sgx.h | 23 +-
arch/x86/kernel/cpu/common.c | 9 +
arch/x86/kernel/cpu/sgx/encl.c | 46 +++-
arch/x86/kernel/cpu/sgx/ioctl.c | 53 +++-
arch/x86/kernel/cpu/sgx/main.c | 460 ++++++++++++++++++++++++++++++-
arch/x86/kernel/cpu/sgx/virt.c | 22 ++
10 files changed, 658 insertions(+), 25 deletions(-)
--
2.17.1
next reply other threads:[~2022-03-15 1:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 1:02 Cathy Zhang [this message]
2022-03-15 1:02 ` [RFC PATCH v2 01/10] x86/sgx: Introduce mechanism to prevent new initializations of EPC pages Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 02/10] x86/sgx: Provide VA page non-NULL owner Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 03/10] x86/sgx: Save enclave pointer for VA page Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 04/10] x86/sgx: Keep record for SGX VA and Guest page type Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 05/10] x86/sgx: Save the size of each EPC section Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 06/10] x86/sgx: Forced EPC page zapping for EUPDATESVN Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 07/10] x86/sgx: Define error codes for ENCLS[EUPDATESVN] Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 08/10] x86/sgx: Implement ENCLS[EUPDATESVN] Cathy Zhang
2022-03-15 1:02 ` [RFC PATCH v2 09/10] x86/cpu: Call ENCLS[EUPDATESVN] procedure in microcode update Cathy Zhang
[not found] ` <[email protected]>
2022-03-16 15:42 ` Dave Hansen
[not found] ` <[email protected]>
2022-03-16 15:47 ` Dave Hansen
2022-03-15 1:03 ` [RFC PATCH v2 10/10] x86/sgx: Call ENCLS[EUPDATESVN] during SGX initialization Cathy Zhang
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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