public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Sneddon <daniel.sneddon@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "Shutemov, Kirill" <kirill.shutemov@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, "Gomez Iglesias,
	Antonio" <antonio.gomez.iglesias@intel.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Subject: Re: [PATCH] x86/apic: Don't disable x2APIC if locked
Date: Wed, 10 Aug 2022 12:40:37 -0700	[thread overview]
Message-ID: <341ea6e9-d8f3-ee7a-6794-67408abbf047@linux.intel.com> (raw)
In-Reply-To: <d4bcb22e-224c-d256-cb93-3ff6ed89a7d0@intel.com>

On 8/10/22 11:52, Dave Hansen wrote:
> On 8/10/22 11:30, Daniel Sneddon wrote:
>>> If it's going to be on one server CPU that's coming out in ten years,
>>> then we can hold off.
>> SPR will certainly be sooner than 10 years, and with distros running on LTS
>> kernels, it is probably worth backporting.  Since this isn't a bug fix (not a sw
>> bug anyway), is this something I can just CC stable or is there a better way to
>> say "Yes, this is a new feature, BUT, you really want it anyway"?
> 
> It it going to be *forced* on those SPR system?  In other words, is it a
> little BIOS switch that users can flip?  Is there any non-kernel
> workaround if a user hits this, or is the entire burden of this going to
> be foisted on the kernel?
It won't be forced, BUT, certain features won't be available if the APIC isn't
locked.  According to the documentation SGX and TDX won't be available if you
don't lock the APIC.  So, yes, you don't have to fix it in the kernel, but you
may lose access to features if you don't.
> 
> The worst case scenario would be if a user has managed to compile a
> CONFIG_X86_X2APIC=n kernel and is happily running along until they get a
> microcode update, reboot and can't boot any more.
That _shouldn't_ happen as it is only on new hardware, so a ucode update
_shouldn't_ cause a crash.
> 
> A less-bad, but still nasty situation would be someone who is booting
> with nox2apic, who also suddenly loses the ability to boot until they
> figure out why their kernel is #GP'ing and oopsing early in boot and
> remove nox2apic.

That should only happen if they update their BIOS settings in such a way that
the APIC is locked (e.g, SGX or TDX is enabled) on an existing SPR system.
> I think we need a bit more information on how this thing will get
> deployed before we really know if it needs to be in stable kernels or
> not.  For instance, if Intel really views this as an always-on security
> mitigation, that's a different story than if this is, say, a performance
> tweak.
Well, it is certainly an always on thing if you want SGX or TDX.  If you're on
SPR or newer with either of those enabled, then the APIC will be locked.  If
you're using an image that works with nox2apic on pre-SPR hardware and put it on
SPR hardware, you'll hang trying to boot.  In that case you'll either have to
remove the nox2apic option or tweak your BIOS so you're not locked, BUT, I
suspect those BIOS options aren't going to be super clear about what to turn off
to make sure you're not locked.

You can boot an old kernel without this patch, or even without X2APIC support,
but you may have to mess with the BIOS to get there.  The good news is that it
should only affect new systems as this isn't on any existing production hardware
and isn't planned on being pushed out to existing products via ucode updates.

  reply	other threads:[~2022-08-10 19:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 23:40 [PATCH] x86/apic: Don't disable x2APIC if locked Daniel Sneddon
2022-08-10 18:01 ` Dave Hansen
2022-08-10 18:30   ` Daniel Sneddon
2022-08-10 18:52     ` Dave Hansen
2022-08-10 19:40       ` Daniel Sneddon [this message]
2022-08-10 19:59         ` Dave Hansen
2022-08-10 20:06           ` Daniel Sneddon
2022-08-10 20:29             ` Daniel Sneddon
2022-08-10 21:57               ` Dave Hansen
2022-08-10 22:06         ` Thomas Gleixner
2022-08-10 22:56           ` Daniel Sneddon
2022-08-10 23:03           ` Daniel Sneddon
2022-08-10 23:09             ` Dave Hansen
2022-08-10 23:38               ` Daniel Sneddon
2022-08-10 23:44                 ` Dave Hansen
2022-08-11  0:01                   ` Daniel Sneddon
2022-08-11  0:38                     ` Thomas Gleixner
2022-08-11  0:59                       ` Daniel Sneddon
2022-08-11 10:08                         ` Huang, Kai
2022-08-11  0:17                 ` Thomas Gleixner
2022-08-11  0:40                   ` Daniel Sneddon
2022-08-11  8:29               ` Huang, Kai

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=341ea6e9-d8f3-ee7a-6794-67408abbf047@linux.intel.com \
    --to=daniel.sneddon@linux.intel.com \
    --cc=antonio.gomez.iglesias@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --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