[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a3661d5-3539-4443-88da-003dea920188@linux.intel.com>
Date: Thu, 11 Jan 2024 06:19:46 -0800
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>
Cc: x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Tom Lendacky <thomas.lendacky@....com>, linux-coco@...ts.linux.dev,
linux-kernel@...r.kernel.org, Dexuan Cui <decui@...rosoft.com>,
Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
Subject: Re: [PATCHv2] x86/mm: Fix memory encryption features advertisement
On 1/11/2024 3:12 AM, Kirill A. Shutemov wrote:
> When memory encryption is enabled, the kernel prints the encryption
> flavor that the system supports.
>
> The check assumes that everything is AMD SME/SEV if it doesn't have
> the TDX CPU feature set.
>
> Hyper-V vTOM sets cc_vendor to CC_VENDOR_INTEL when it runs as L2 guest
> on top of TDX, but not X86_FEATURE_TDX_GUEST. Hyper-V only needs memory
> encryption enabled for I/O without the rest of CoCo enabling.
>
> To avoid confusion, check the cc_vendor directly.
>
> Possible alternative is to completely removing the print statement.
> For a regular TDX guest, the kernel already prints a message indicating
> that it is booting on TDX. Similarly, AMD and Hyper-V can also display
> a message during their enumeration process.
With this change, will it print "Intel TDX" for Hyper-V?
IMO, since there is already a debug message for type identification, we
can remove this part.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Cc: Dexuan Cui <decui@...rosoft.com>
> Cc: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
> ---
> arch/x86/mm/mem_encrypt.c | 56 +++++++++++++++++++++------------------
> 1 file changed, 30 insertions(+), 26 deletions(-)
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index c290c55b632b..d035bce3a2b0 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -42,38 +42,42 @@ bool force_dma_unencrypted(struct device *dev)
>
> static void print_mem_encrypt_feature_info(void)
> {
> - pr_info("Memory Encryption Features active:");
> + pr_info("Memory Encryption Features active: ");
>
> - if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
> - pr_cont(" Intel TDX\n");
> - return;
> - }
> + switch (cc_vendor) {
> + case CC_VENDOR_INTEL:
> + pr_cont("Intel TDX\n");
> + break;
> + case CC_VENDOR_AMD:
> + pr_cont("AMD");
>
> - pr_cont(" AMD");
> -
> - /* Secure Memory Encryption */
> - if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
> + /* Secure Memory Encryption */
> + if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
> /*
> * SME is mutually exclusive with any of the SEV
> * features below.
> - */
> - pr_cont(" SME\n");
> - return;
> + */
> + pr_cont(" SME\n");
> + return;
> + }
> +
> + /* Secure Encrypted Virtualization */
> + if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> + pr_cont(" SEV");
> +
> + /* Encrypted Register State */
> + if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
> + pr_cont(" SEV-ES");
> +
> + /* Secure Nested Paging */
> + if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
> + pr_cont(" SEV-SNP");
> +
> + pr_cont("\n");
> + break;
> + default:
> + pr_cont("Unknown\n");
> }
> -
> - /* Secure Encrypted Virtualization */
> - if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> - pr_cont(" SEV");
> -
> - /* Encrypted Register State */
> - if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
> - pr_cont(" SEV-ES");
> -
> - /* Secure Nested Paging */
> - if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
> - pr_cont(" SEV-SNP");
> -
> - pr_cont("\n");
> }
>
> /* Architecture __weak replacement functions */
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Powered by blists - more mailing lists