From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96FD5C433EF for ; Fri, 6 May 2022 15:32:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B11546B0072; Fri, 6 May 2022 11:32:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A9A256B0073; Fri, 6 May 2022 11:32:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93A1C6B0074; Fri, 6 May 2022 11:32:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 809396B0072 for ; Fri, 6 May 2022 11:32:12 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4A55C2FA80 for ; Fri, 6 May 2022 15:32:12 +0000 (UTC) X-FDA: 79435709304.20.96E88C7 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf06.hostedemail.com (Postfix) with ESMTP id 6111518003C for ; Fri, 6 May 2022 15:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651851131; x=1683387131; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=LfMNbao3ZjCq5W5xkjvkRFQQK+D46fsTZ0ZtKYEZ5ow=; b=funjyHkmG3TYXwGyYO0deiuEn/tBxbQdZ/WDUTnGpDj7dniCG6da2ybG FDoWme0NSF/yCoRGDUuzkLl6EpBS/EtTSpAD+Z3smbnjtyUYRWO1Z6TLp MNx6rC8aGRaYyog3YC5BeHhcyXsKf/wtANC9KeC4zDNP6NPd/LnN20cet vom/NYedVpVM09e12pTsSDmsalIWCNPuR0Y48QMRLjfuhCfdJc8Kqgb/E Rv/sDSNI+Te4U6lNiNIVercKB1CrDMVbINADvkjcV/LvtWC2e2YDYAL4S EvmoGV54xofwuwoTKdD56BBmPcMLRuN+gWy7g+nx3SRm1DQjAF5zjoqjl A==; X-IronPort-AV: E=McAfee;i="6400,9594,10339"; a="268101343" X-IronPort-AV: E=Sophos;i="5.91,203,1647327600"; d="scan'208";a="268101343" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 08:32:09 -0700 X-IronPort-AV: E=Sophos;i="5.91,203,1647327600"; d="scan'208";a="812430096" Received: from nnwaiwux-mobl.amr.corp.intel.com (HELO [10.212.56.26]) ([10.212.56.26]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 08:32:08 -0700 Message-ID: <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> Date: Fri, 6 May 2022 08:32:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption Content-Language: en-US To: Borislav Petkov , Martin Fernandez Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org, "Williams, Dan J" , Ben Widawsky , "Huang, Kai" References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6111518003C X-Stat-Signature: 3urtoz5e9g1fc3hgk73pfm5dds9f4fpw Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=funjyHkm; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf06.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=dave.hansen@intel.com X-Rspam-User: X-HE-Tag: 1651851129-730667 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/6/22 05:44, Borislav Petkov wrote: >> Dave Hansen pointed those out in a previuos patch serie, here is the >> quote: >> >>> CXL devices will have normal RAM on them, be exposed as "System RAM" and >>> they won't have encryption capabilities. I think these devices were >>> probably the main motivation for EFI_MEMORY_CPU_CRYPTO. > So this would mean that if a system doesn't have CXL devices and has > TME/SME/SEV-* enabled, then it is running with encrypted memory. > > Which would then also mean, you don't need any of that code - you only > need to enumerate CXL devices which, it seems, do not support memory > encryption, and then state that memory encryption is enabled on the > whole system, except for the memory of those devices. CXL devices are just the easiest example to explain, but they are not the only problem. For example, Intel NVDIMMs don't support TDX (or MKTME with integrity) since TDX requires integrity protection and NVDIMMs don't have metadata space available. Also, if this were purely a CXL problem, I would have expected this to have been dealt with in the CXL spec alone. But, this series is actually driven by an ACPI spec. That tells me that we'll see these mismatched encryption capabilities in many more places than just CXL devices.