All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cathy Zhang <cathy.zhang@intel.com>
To: linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: dave.hansen@intel.com, ashok.raj@intel.com, cathy.zhang@intel.com
Subject: [RFC PATCH v2 00/10] Support microcode updates affecting SGX
Date: Tue, 15 Mar 2022 09:02:50 +0800	[thread overview]
Message-ID: <20220315010300.10199-1-cathy.zhang@intel.com> (raw)

v1:
https://lore.kernel.org/all/1742be9e-c18e-28c9-75c8-144bf1f6a311@intel.com/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/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 (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


             reply	other threads:[~2022-03-15  1:02 UTC|newest]

Thread overview: 24+ 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-17  4:12   ` Jarkko Sakkinen
2022-03-17 14:08     ` Zhang, Cathy
2022-03-17 18:52       ` Jarkko Sakkinen
2022-03-18  2:33         ` Zhang, Cathy
2022-03-18 16:23           ` Reinette Chatre
2022-03-22  1:11             ` Zhang, Cathy
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
2022-03-16  9:46   ` Jethro Beekman
2022-03-16 10:24     ` Jethro Beekman
2022-03-16 15:47       ` Dave Hansen
2022-03-18  9:06         ` Jethro Beekman
2022-03-22  1:35           ` Zhang, Cathy
2022-03-16 15:42     ` Dave Hansen
2022-03-18  9:04       ` Jethro Beekman
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 \
    --in-reply-to=20220315010300.10199-1-cathy.zhang@intel.com \
    --to=cathy.zhang@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.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.