public inbox for linux-sgx@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Cathy Zhang <cathy.zhang@intel.com>,
	linux-sgx@vger.kernel.org, x86@kernel.org, "Raj,
	Ashok" <ashok.raj@intel.com>
Subject: Re: [RFC PATCH 00/11] Support microcode updates affecting SGX
Date: Wed, 9 Mar 2022 11:52:26 -0800	[thread overview]
Message-ID: <26cbb03e-dd9e-2f1d-0454-7e9b00b0927e@intel.com> (raw)
In-Reply-To: <YikBvBNwpWqDxKQl@zn.tnic>

On 3/9/22 11:36, Borislav Petkov wrote:
> On Wed, Mar 09, 2022 at 11:14:22AM -0800, Dave Hansen wrote:
>> Let's imagine an extreme (thankfully imaginary) case: SGX has been
>> totally broken by some attack.  All running enclaves might have been
>> compromised.  A magical microcode update comes and saves the day and
>> mitigates the attack.
>>
>> From the hardware perspective, at the time of the microcode update, the
>> (presumably compromised) enclaves *can* still run.
> Here's where you lost me: the enclaves are presumably compromised and
> yet you wanna leave them running?! Isn't the strategy to kill them to
> limit the spread of whatever has compromised them?

Killing them immediately is a totally valid policy.  But, I think it's
also a valid policy to continue to let them run.  Maybe you know they
were not vulnerable to whatever got mitigated.  Or, maybe they're
sufficiently sandboxed that they are not of any concern.  You want new
enclaves to be able to attest to the new microcode, but you're just not
that worried about the old ones.

This mechanism allows userspace to separate the "update the microcode"
and "destroy the enclaves" and implement a policy which separates them
(or doesn't).

In either case, the specific demand from end users for this flexibility
is clearly lacking.  I'm sure Cathy and Ashok will get working to flesh
that out.

  reply	other threads:[~2022-03-09 19:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 10:40 [RFC PATCH 00/11] Support microcode updates affecting SGX Cathy Zhang
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 [this message]
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=26cbb03e-dd9e-2f1d-0454-7e9b00b0927e@intel.com \
    --to=dave.hansen@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=cathy.zhang@intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --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