From: Daniel Sneddon <daniel.sneddon@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
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
Date: Wed, 10 Aug 2022 17:40:02 -0700 [thread overview]
Message-ID: <244c4bc6-c5ec-dcca-1ffe-5f00fd0091f3@linux.intel.com> (raw)
In-Reply-To: <87o7wrtyze.ffs@tglx>
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!
next prev parent reply other threads:[~2022-08-11 0:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 23:40 [PATCH] x86/apic: Don't disable x2APIC if locked Daniel Sneddon
2022-08-10 18:01 ` Dave Hansen
2022-08-10 18:30 ` Daniel Sneddon
2022-08-10 18:52 ` Dave Hansen
2022-08-10 19:40 ` Daniel Sneddon
2022-08-10 19:59 ` Dave Hansen
2022-08-10 20:06 ` Daniel Sneddon
2022-08-10 20:29 ` Daniel Sneddon
2022-08-10 21:57 ` Dave Hansen
2022-08-10 22:06 ` Thomas Gleixner
2022-08-10 22:56 ` Daniel Sneddon
2022-08-10 23:03 ` Daniel Sneddon
2022-08-10 23:09 ` Dave Hansen
2022-08-10 23:38 ` Daniel Sneddon
2022-08-10 23:44 ` Dave Hansen
2022-08-11 0:01 ` Daniel Sneddon
2022-08-11 0:38 ` Thomas Gleixner
2022-08-11 0:59 ` Daniel Sneddon
2022-08-11 10:08 ` Huang, Kai
2022-08-11 0:17 ` Thomas Gleixner
2022-08-11 0:40 ` Daniel Sneddon [this message]
2022-08-11 8:29 ` Huang, Kai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=244c4bc6-c5ec-dcca-1ffe-5f00fd0091f3@linux.intel.com \
--to=daniel.sneddon@linux.intel.com \
--cc=antonio.gomez.iglesias@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.