From: Cathy Zhang <cathy.zhang@intel.com>
To: linux-sgx@vger.kernel.org, x86@kernel.org
Cc: dave.hansen@intel.com, cathy.zhang@intel.com
Subject: [RFC PATCH 00/11] Support microcode updates affecting SGX
Date: Wed, 9 Mar 2022 18:40:39 +0800 [thread overview]
Message-ID: <20220309104050.18207-1-cathy.zhang@intel.com> (raw)
Users hate reboots. This lets SGX enclaves attest to updated microcode
without a reboot.
== 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.
Today, many microcode updates _can_ be applied without a reboot.
But users have strongly and specifically expressed a desire to
perform *any* microcode update on a running system without a reboot.
This work is a direct result of those user requests and lets SGX
enclaves take full advantage of microcode updates without a reboot.
== 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. This is expected
to be triggered by administrators via sysfs at some convenient time
after a microcode update, probably by the microcode update tooling
itself.
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. Enclaves
are expected to be designed to be volatile and survive termination at
any time gracefully.
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/cover.1644274683.git.reinette.chatre@intel.com/T/
Here is the spec for your reference:
https://cdrdv2.intel.com/v1/dl/getContent/648682?explicitVersion=true
Cathy Zhang (11):
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/microcode: Expose EUPDATESVN procedure via sysfs
x86/sgx: Call ENCLS[EUPDATESVN] during SGX initialization
Documentation/x86/sgx: Document EUPDATESVN sysfs file
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/microcode/core.c | 44 ++
arch/x86/kernel/cpu/sgx/encl.c | 46 +-
arch/x86/kernel/cpu/sgx/ioctl.c | 53 +-
arch/x86/kernel/cpu/sgx/main.c | 469 +++++++++++++++++-
arch/x86/kernel/cpu/sgx/virt.c | 22 +
.../ABI/testing/sysfs-devices-system-cpu | 14 +
Documentation/x86/sgx.rst | 43 ++
12 files changed, 759 insertions(+), 25 deletions(-)
--
2.17.1
next reply other threads:[~2022-03-09 10:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 10:40 Cathy Zhang [this message]
2022-03-09 10:40 ` [RFC PATCH 01/11] x86/sgx: Introduce mechanism to prevent new initializations of EPC pages Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 02/11] x86/sgx: Provide VA page non-NULL owner Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 03/11] x86/sgx: Save enclave pointer for VA page Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 04/11] x86/sgx: Keep record for SGX VA and Guest page type Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 05/11] x86/sgx: Save the size of each EPC section Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 06/11] x86/sgx: Forced EPC page zapping for EUPDATESVN Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 07/11] x86/sgx: Define error codes for ENCLS[EUPDATESVN] Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 08/11] x86/sgx: Implement ENCLS[EUPDATESVN] Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 09/11] x86/microcode: Expose EUPDATESVN procedure via sysfs Cathy Zhang
2022-03-09 11:20 ` Borislav Petkov
2022-03-09 15:42 ` Dave Hansen
2022-03-09 15:48 ` Borislav Petkov
2022-03-10 5:15 ` Zhang, Cathy
2022-03-09 10:40 ` [RFC PATCH 10/11] x86/sgx: Call ENCLS[EUPDATESVN] during SGX initialization Cathy Zhang
2022-03-09 10:40 ` [RFC PATCH 11/11] Documentation/x86/sgx: Document EUPDATESVN sysfs file Cathy Zhang
2022-03-09 19:01 ` [RFC PATCH 00/11] Support microcode updates affecting SGX Thomas Gleixner
2022-03-09 19:14 ` Dave Hansen
2022-03-09 19:36 ` Borislav Petkov
2022-03-09 19:52 ` Dave Hansen
2022-03-09 20:15 ` Thomas Gleixner
2022-03-09 20:32 ` Dave Hansen
2022-03-09 20:48 ` Raj, Ashok
2022-03-09 23:09 ` Thomas Gleixner
2022-03-10 5:24 ` Zhang, Cathy
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=20220309104050.18207-1-cathy.zhang@intel.com \
--to=cathy.zhang@intel.com \
--cc=dave.hansen@intel.com \
--cc=linux-sgx@vger.kernel.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).