Message ID | 20240111111224.25289-1-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-23457-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp1372041dyi; Thu, 11 Jan 2024 03:13:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IGkaPCbBBhtaT7XhAmVUJGGhrE19SWifkhnsfYdhzVOWTippR+yR6Z81oU7hykzFI5enuyg X-Received: by 2002:a2e:920e:0:b0:2cc:df53:52fc with SMTP id k14-20020a2e920e000000b002ccdf5352fcmr337839ljg.60.1704971584435; Thu, 11 Jan 2024 03:13:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704971584; cv=none; d=google.com; s=arc-20160816; b=aCXzOB3vE759zggjgJJhYOzcnfNT2/AFe63a7S0Wqc0Vktj5PDw4gNX1aQxoSllx+e mTTS2zo97zfQ01QvwYEa9VgNSKOfNq/3UfGVlx4dW9Wu1eajktqb4AJvYMJOS4s//HOE bRcyuqUXoZgQcvtxuu2xySPoeDvXUpuKkA+KAcbyLL1ZumoyU2hVqexiVdqLd/TBQ/8+ BVJp7MQ0I8PwFF/ljcA+9zFxhXXoW39MquxBBQaQiwt79nUchW8c1wcZE65RGXRhqspx Ez5ZpmDyLP0QzP7C3Zg0yDNHRH01oRvU33LDEEWX4olzX5NgHkQ999pUMNbJwyNGnJmx L2yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=WLHP9iQfo0ejhyQibKLBu2ezQu82J0TUJoj7t20lXCs=; fh=p+C5FdXXe4eutUhPtPhzvBdtxCE8VDakaXeY9Jsq0U0=; b=ZsgfM5IEmdY/KqhcZG04Gl/qYAkoAcZFG7mqS3Qj5eeCxuZbTmkoSEFfkgfrzHfDTE SVpNebMya+fuz0GnHJdC5nJiEYz9TzUaduMFZ+3xr4SzsF4HJG4Ut3U7T0Sy5SfQQG2x vgOAx8XjvkDSasCn8rozbGWCTXaf+ZON+1NE2BQJzIwK8QA7XiksZUIDs09mjcM0cHYo za1U5HhpzBmbmzAQYHSpLyBSoRcMYW7vjFGDaIswXW8Ba+WpTEjPNQtz/g2gsXc/aTm8 6OcUmLDMkpV+f8rUlUmzS4hXKheyswRTcj0arO+1Z7BbS88iak+6bywgX8VM4OG4SDk+ 6Aew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W61qeUVg; spf=pass (google.com: domain of linux-kernel+bounces-23457-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23457-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id b4-20020a170906150400b00a2b61bd354fsi414891ejd.283.2024.01.11.03.13.04 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 03:13:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23457-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W61qeUVg; spf=pass (google.com: domain of linux-kernel+bounces-23457-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23457-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DD46B1F23C19 for <ouuuleilei@gmail.com>; Thu, 11 Jan 2024 11:13:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 36E01154AB; Thu, 11 Jan 2024 11:12:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="W61qeUVg" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FE6314F88 for <linux-kernel@vger.kernel.org>; Thu, 11 Jan 2024 11:12:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704971554; x=1736507554; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=1YFtBXWVelzOCij9mu8FZw930rKm1mM6tLkMC1PxwA8=; b=W61qeUVgV7B7ZJ/4uZmGD/ID7cFfikWkAYSIqDLkThXVDJGGIsBRHnhz n1h6WJqTnxDhvQ9jCr5Snpbl8M1AqvNqTn7p+bl6VBgtCJ1Rr8mXYd6nz j1VTXSjcWmOkz1zZN/foNsYQA2XxzgLQhx+L69Q97FZleQ38j5tuC2Nui vluMKWTh6TZlf3FmIHTtw05G9p3e7xm+1OrUv4aM0iVueGtC9ZgYXr+8D yVwWbkgHF5cqg4QqIGj9pqAEcpA9jsHl9iQULcm67Cf+cEnXgTMuhzvcD LKfD3mSgTRzWfDYkv1Mojce0U0kBrRTeLCJ2SJgZGIXv2QGGZMVGv6qX7 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="6175587" X-IronPort-AV: E=Sophos;i="6.04,186,1695711600"; d="scan'208";a="6175587" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 03:12:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,186,1695711600"; d="scan'208";a="24593644" Received: from gcrisanx-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.213.56]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 03:12:30 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id B879810A557; Thu, 11 Jan 2024 14:12:27 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Tom Lendacky <thomas.lendacky@amd.com>, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Dexuan Cui <decui@microsoft.com>, Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Subject: [PATCHv2] x86/mm: Fix memory encryption features advertisement Date: Thu, 11 Jan 2024 14:12:24 +0300 Message-ID: <20240111111224.25289-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787733341155678338 X-GMAIL-MSGID: 1787792284077518896 |
Series |
[PATCHv2] x86/mm: Fix memory encryption features advertisement
|
|
Commit Message
Kirill A. Shutemov
Jan. 11, 2024, 11:12 a.m. UTC
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.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
---
arch/x86/mm/mem_encrypt.c | 56 +++++++++++++++++++++------------------
1 file changed, 30 insertions(+), 26 deletions(-)
Comments
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@linux.intel.com> > Cc: Dexuan Cui <decui@microsoft.com> > Cc: Jeremi Piotrowski <jpiotrowski@linux.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 */
On 11/01/2024 15:19, Kuppuswamy Sathyanarayanan wrote: > > > 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? Yes, I just tested on AMD and Intel and the print is accurate now. Thanks. Reviewed-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> > > IMO, since there is already a debug message for type identification, we > can remove this part. > If that's the only way to get a fix merged then so be it, but I appreciate having the possibility of greping for a single prefix for either vendor that the current code provides. >> >> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> >> Cc: Dexuan Cui <decui@microsoft.com> >> Cc: Jeremi Piotrowski <jpiotrowski@linux.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 */ >
On 1/11/24 05:12, 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. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Cc: Dexuan Cui <decui@microsoft.com> > Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.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
On 1/11/2024 6:19 AM, Kuppuswamy Sathyanarayanan wrote: > > > 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@linux.intel.com> >> Cc: Dexuan Cui <decui@microsoft.com> >> Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> >> --- Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.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 */ >
On Thu, 2024-01-11 at 14:12 +0300, 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. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Cc: Dexuan Cui <decui@microsoft.com> > Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Seems this fix is for userspace running in hyperv environment being able to use some easy grep to get which coco vendor it is running on? If so I think it would be nice to mention it too. Acked-by: Kai Huang <kai.huang@intel.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 */
On Tue, Jan 16, 2024 at 10:36:10AM +0000, Huang, Kai wrote: > On Thu, 2024-01-11 at 14:12 +0300, 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. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > Cc: Dexuan Cui <decui@microsoft.com> > > Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> > > Seems this fix is for userspace running in hyperv environment being able to use > some easy grep to get which coco vendor it is running on? Making decision in userspace by grepping dmesg is bad idea and nobody should do this. It can easily give false result: dmesg is not ABI, format can change and ring buffer has finite size, the message can be overridden. If we need a way for userspace to discover which CoCo environment it runs on, we need proper ABI for that. Maybe sysfs file or something. > If so I think it would be nice to mention it too. > > Acked-by: Kai Huang <kai.huang@intel.com> Thanks.
On Tue, 2024-01-16 at 13:58 +0300, kirill.shutemov@linux.intel.com wrote: > On Tue, Jan 16, 2024 at 10:36:10AM +0000, Huang, Kai wrote: > > On Thu, 2024-01-11 at 14:12 +0300, 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. > > > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > > Cc: Dexuan Cui <decui@microsoft.com> > > > Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> > > > > Seems this fix is for userspace running in hyperv environment being able to use > > some easy grep to get which coco vendor it is running on? > > Making decision in userspace by grepping dmesg is bad idea and nobody > should do this. It can easily give false result: dmesg is not ABI, format > can change and ring buffer has finite size, the message can be overridden. > > If we need a way for userspace to discover which CoCo environment it runs > on, we need proper ABI for that. Maybe sysfs file or something. Yeah agreed. :-)
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 */