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]

Date:   Thu, 11 Aug 2022 02:17:41 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        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>,
        "Huang, Kai" <kai.huang@...el.com>
Cc:     "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        "Gomez Iglesias, Antonio" <antonio.gomez.iglesias@...el.com>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Subject: Re: [PATCH] x86/apic: Don't disable x2APIC if locked

On Wed, Aug 10 2022 at 16:38, Daniel Sneddon wrote:
> On 8/10/22 16:09, Dave Hansen wrote:
>> config INTEL_TDX_GUEST
>>         bool "Intel TDX (Trust Domain Extensions) - Guest Support"
>>         depends on X86_64 && CPU_SUP_INTEL
>>         depends on X86_X2APIC
>
> So I got some more input.  SPR and newer will lock the APIC.  Older products
> will get a ucode update, but that ucode update won't include the APIC lock.  So,
> on non-SPR parts do we still want to make SGX depend on X2APIC?

What is the ucode update doing on pre SPR parts?
Just providing magic voodoo which pretends to be safe?

The public available documentation for this is a huge pile of void.

The point is that if the SGX attestation will fail when X2APIC is not
enforced on the host as of 'some magic dates in 2023' according to the
documentation I pointed to, then any pre SPR SGX capable system is going
to be disfunctional vs. SGX at one of those magic dates.

Some people inside a particular company need to get their act together
and either make this consistent or provide some coherent information why
this is not required for pre SPR parts and why SPR needs to have it.

Thanks,

        tglx