linux-kernel - Re: [PATCH] x86/apic: Don't disable x2APIC if locked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d4bcb22e-224c-d256-cb93-3ff6ed89a7d0@intel.com>
Date:   Wed, 10 Aug 2022 11:52:48 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "Shutemov, Kirill" <kirill.shutemov@...el.com>
Cc:     "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/apic: Don't disable x2APIC if locked

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?

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.

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.

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.