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
| ||
|
Message-ID: <ae9e37c2-3f50-4098-9b0e-771d10262c6b@linux.microsoft.com> Date: Tue, 5 Dec 2023 18:27:50 +0100 From: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com> To: Borislav Petkov <bp@...en8.de>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com> Cc: Tom Lendacky <thomas.lendacky@....com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org Subject: Re: [PATCH] x86/coco, x86/sev: Use cpu_feature_enabled() to detect SEV guest flavor On 05/12/2023 17:00, Borislav Petkov wrote: > On Tue, Dec 05, 2023 at 06:14:37PM +0300, Kirill A. Shutemov wrote: >> My point is that if you need to check for SEV you need to check SEV, not >> CC_ATTR. CC_ATTRs only make sense in generic code that deals with multiple >> CoCo environments. > > That makes more sense. So given this series, what is the canonical way to expose sub-features of TDX/SNP going forward? X86_FEATURE_xxx for every one that needs to be queried in TDX/SNP specific code? I see that in [1] X86_FEATURE_SNP_SECURE_TSC is being proposed. How about the CC_ATTR_TDX_MODULE_CALLS (perhaps better called TDX_TDCALL or something) that I'm proposing in the other thread [2]? VTOM? SVSM? We can also export amd_cc_platform_has() and intel_cc_platform_has() for such cases. But we really need is to agree which to use when (X86_FEATURE vs CC_ATTR). [1]: https://lore.kernel.org/lkml/20231128125959.1810039-10-nikunj@amd.com/ [2]: https://lore.kernel.org/lkml/20231122170106.270266-2-jpiotrowski@linux.microsoft.com/ Jeremi > > So that commit already says "If future support is added for other > memory encryption technologies, the use of CC_ATTR_GUEST_MEM_ENCRYPT > can be updated, as required." > > And what this test needs to do is to check: > > if (guest type >= SEV) > > meaning SEV and -ES and -SNP. > > I'm wondering if we should export amd_cc_platform_has() for such > cases... > > The logic being, we're calling a SEV-specific function so using > cc_platform_has() in there is the wrong layer. > > Tom? >
Powered by blists - more mailing lists