Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 10 Aug 2022 17:40:02 -0700 | From | Daniel Sneddon <> | 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!
| ![\](/images/icornerr.gif) |