All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Cathy Zhang <cathy.zhang@intel.com>,
	linux-sgx@vger.kernel.org, x86@kernel.org
Cc: jarkko@kernel.org, reinette.chatre@intel.com,
	dave.hansen@intel.com, ashok.raj@intel.com,
	cathy.zhang@intel.com, chao.p.peng@linux.intel.com,
	yang.zhong@intel.com
Subject: Re: [PATCH v5 0/9] Support microcode updates affecting SGX
Date: Tue, 24 May 2022 21:15:00 +0200	[thread overview]
Message-ID: <87r14izqrv.ffs@tglx> (raw)
In-Reply-To: <20220520103904.1216-1-cathy.zhang@intel.com>

Cathy,

On Fri, May 20 2022 at 18:38, Cathy Zhang wrote:
> 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.

please don't take this personaly.

What users want and what's technically correct are two different things.

Fact is that late microcode updates especially those which change
features, add/remove functionality are simply broken. This has been
discussed to death already and I'm not going to find all the various
threads which provided that information. lore.kernel.org has excellent
search capabilities.

As a summary, there is a long standing request that for late loading
microcode needs to come with machine readable information about the
nature of the update which tells the kernel whether there are changes
which cannot be applied post boot.

This was agreed on by Intel folks and until this materializes any
attempt to load microcode late has to be considered as unsupported. This
is going on for years now and has been ignored.

As a consequence we are not adding a special SGX workaround for
something which is known to be broken.

What we are going to do and I'm fasttracking this is:

 https://lore.kernel.org/all/20220524185324.28395-1-bp@alien8.de

which make the SGX workaround moot.

Thanks

        tglx

  parent reply	other threads:[~2022-05-24 19:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 10:38 [PATCH v5 0/9] Support microcode updates affecting SGX Cathy Zhang
2022-05-20 10:38 ` [PATCH v5 1/9] x86/sgx: Introduce mechanism to prevent new initializations of EPC pages Cathy Zhang
2022-05-20 19:05   ` Jarkko Sakkinen
2022-05-20 10:38 ` [PATCH v5 2/9] x86/sgx: Save enclave pointer for VA page Cathy Zhang
2022-05-20 19:07   ` Jarkko Sakkinen
2022-05-20 10:38 ` [PATCH v5 3/9] x86/sgx: Keep record for SGX VA and Guest page type Cathy Zhang
2022-05-20 19:11   ` Jarkko Sakkinen
2022-05-23  0:06     ` Zhang, Cathy
2022-05-23  6:09       ` Zhang, Cathy
2022-05-23 19:19         ` Jarkko Sakkinen
2022-05-20 10:38 ` [PATCH v5 4/9] x86/sgx: Save the size of each EPC section Cathy Zhang
2022-05-20 10:39 ` [PATCH v5 5/9] x86/sgx: Forced EPC page zapping for EUPDATESVN Cathy Zhang
2022-05-20 10:39 ` [PATCH v5 6/9] x86/sgx: Define error codes for ENCLS[EUPDATESVN] Cathy Zhang
2022-05-20 10:39 ` [PATCH v5 7/9] x86/sgx: Implement ENCLS[EUPDATESVN] Cathy Zhang
2022-05-20 10:39 ` [PATCH v5 8/9] x86/cpu: Call ENCLS[EUPDATESVN] procedure in microcode update Cathy Zhang
2022-05-20 10:39 ` [PATCH v5 9/9] x86/sgx: Call ENCLS[EUPDATESVN] during SGX initialization Cathy Zhang
2022-05-24 19:15 ` Thomas Gleixner [this message]
2022-05-24 19:26   ` [PATCH v5 0/9] Support microcode updates affecting SGX Borislav Petkov

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=87r14izqrv.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=ashok.raj@intel.com \
    --cc=cathy.zhang@intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=dave.hansen@intel.com \
    --cc=jarkko@kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=x86@kernel.org \
    --cc=yang.zhong@intel.com \
    /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.