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:   Wed, 10 Aug 2022 17:40:02 -0700
From:   Daniel Sneddon <daniel.sneddon@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        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 8/10/22 17:17, Thomas Gleixner wrote:
> 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?
It'll be clearing the buffers so that when someone tries to read data from the
APIC it won't leak data anymore.
> 
> The public available documentation for this is a huge pile of void.
I don't disagree with that.
> 
> 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.

I'll try to get more clarification, and more importantly, get that published
somewhere.

> 
> Thanks,
> 
>         tglx
> 
> 
Thanks for the input!