[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231110164557.GBZU5eRRj9x6dOVOaH@fat_crate.local>
Date: Fri, 10 Nov 2023 17:45:57 +0100
From: Borislav Petkov <bp@...en8.de>
To: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
Cc: Dave Hansen <dave.hansen@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Michael Kelley <mhklinux@...look.com>,
Dexuan Cui <decui@...rosoft.com>, linux-hyperv@...r.kernel.org,
stefan.bader@...onical.com, tim.gardner@...onical.com,
roxana.nicolescu@...onical.com, cascardo@...onical.com,
kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
kirill.shutemov@...ux.intel.com, sashal@...nel.org
Subject: Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption
info
On Fri, Nov 10, 2023 at 04:51:43PM +0100, Jeremi Piotrowski wrote:
> What's semi-correct about checking for CC_VENDOR_INTEL and then
> printing Intel? I can post a v2 that checks CC_ATTR_GUEST_MEM_ENCRYPT
> before printing "TDX".
How is it that you're not seeing the conflict:
Your TD partitioning guest *is* a TDX guest so X86_FEATURE_TDX_GUEST
should be set there. But it isn't. Which means, that is already wrong.
Or insufficient.
if (cc_vendor == CC_VENDOR_INTEL)
just *happens* to work for your case.
What the detection code should do, rather, is:
if (guest type == TD partioning)
set bla;
else if (TDX_CPUID_LEAF_ID)
"normal" TDX guest;
and those rules need to be spelled out so that everyone is on the same
page as to how a TD partitioning guest is detected, how a normal TDX
guest is detected, a SEV-ES, a SNP one, yadda yadda.
> The paravisor *is* telling the guest it is running on one - using a CPUID leaf
> (HYPERV_CPUID_ISOLATION_CONFIG). A paravisor is a hypervisor for a confidential
> guest, that's why paravisor detection shares logic with hypervisor detection.
>
> tdx_early_init() runs extremely early, way before hypervisor(/paravisor) detection.
What?
Why can't tdx_early_init() run CPUID(HYPERV_CPUID_ISOLATION_CONFIG) if
it can't find a valid TDX_CPUID_LEAF_ID and set X86_FEATURE_TDX_GUEST
then?
> Additionally we'd need to sprinkle paravisor checks along with
> existing X86_FEATURE_TDX_GUEST checks. And any time someone adds a new
> feature that depends solely on X86_FEATURE_TDX_GUEST we'd run the
> chance of it breaking things.
Well, before anything, you'd need to define what exactly the guest kernel
needs to do when running as a TD partitioning guest and how exactly that
is going to be detected and checked using the current cc_* and
cpufeatures infra. If it doesn't work with the current scheme, then the
current scheme should be extended.
Then, that should be properly written out:
"if bit X is set, then that is a guest type Y"
"if feature foo present, then so and so are given"
If the current guest type detection is insufficient, then that should be
extended/amended.
That's the only viable way where the kernel would support properly and
reliably a given guest type. There'll be no sprinkling of checks
anywhere.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists