Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Daniel Sneddon <daniel.sneddon@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        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>,
        "Huang, Kai" <kai.huang@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
In-Reply-To: <bff78ad9-57d8-ca82-cc75-0b7e5024116d@linux.intel.com>
References: <20220809234000.783284-1-daniel.sneddon@linux.intel.com>
 <d6ffb489-7024-ff74-bd2f-d1e06573bb82@intel.com>
 <238ea612-5a25-9323-b31f-0a14493db2f7@linux.intel.com>
 <d4bcb22e-224c-d256-cb93-3ff6ed89a7d0@intel.com>
 <341ea6e9-d8f3-ee7a-6794-67408abbf047@linux.intel.com>
 <87r11nu52l.ffs@tglx>
 <83a0d220-1872-caba-4e7e-b6a366655cf2@linux.intel.com>
 <ba80b303-31bf-d44a-b05d-5c0f83038798@intel.com>
 <bff78ad9-57d8-ca82-cc75-0b7e5024116d@linux.intel.com>
Date:   Thu, 11 Aug 2022 02:17:41 +0200
Message-ID: <87o7wrtyze.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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