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 9B18AC433FE for ; Fri, 14 Oct 2022 00:24:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BCC66B0072; Thu, 13 Oct 2022 20:24:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96D0C6B0075; Thu, 13 Oct 2022 20:24:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 834616B0078; Thu, 13 Oct 2022 20:24:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 71A226B0072 for ; Thu, 13 Oct 2022 20:24:55 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 44B1112073C for ; Fri, 14 Oct 2022 00:24:55 +0000 (UTC) X-FDA: 80017659750.12.BDADC4D Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf06.hostedemail.com (Postfix) with ESMTP id C79B218001F for ; Fri, 14 Oct 2022 00:24:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665707093; x=1697243093; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=aE1+hnfKiYR3idWoXlvpbQtseYBiK39vZ4xtmA2EiTA=; b=VMjUjDlzHBzuRZ18e3Uop6FBylf89Sjz0TUrfFx8Q3VxwJvzLolKh3PY ZURxmuxJWrK7+sfcVEi5/vBgEUAYm/YABRbZBu724Yq/ejkIrZWQ7ficd Df6UehzM5g/Lln3wKIKTD3R4/KRxKZ+wYKowJRVpSdpai96k46aEuO2jE I6yFFPwISPMB2EKGhd2UJgM9JIP1ZZFKtONJHpDjkZDV2OppJ1EODeVAC xtcKKIreQggoIpvKR3GjBCSWARu905+tT4le1H616VyLetkHccUXLihel rGwkxF6jFWdWmYmV+6l3A0/eKSp+dht4BMq8QrJnjqvnaqs7N/0PO8W9u w==; X-IronPort-AV: E=McAfee;i="6500,9779,10499"; a="284966470" X-IronPort-AV: E=Sophos;i="5.95,182,1661842800"; d="scan'208";a="284966470" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2022 17:24:52 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10499"; a="660539646" X-IronPort-AV: E=Sophos;i="5.95,182,1661842800"; d="scan'208";a="660539646" Received: from mkucejko-mobl.ger.corp.intel.com (HELO [10.213.24.166]) ([10.213.24.166]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2022 17:24:40 -0700 Message-ID: <09db0198-53d3-bc41-da5a-b518375bbec9@intel.com> Date: Thu, 13 Oct 2022 17:24:35 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v9 0/9] 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, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.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 References: <20220704135833.1496303-1-martin.fernandez@eclypsium.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665707094; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9MQJPeTbnMNyCeEEuwa/wa2cdE5uZ5e19zkxNJdkyHo=; b=KohOjzABvh1w2VdwCVzxG0VocGRMu52ZtvgLtTO6H87ho1B1WX5iI3Zwlg3/l6m7UXgaPD Pw4q6C/slUg14imMJmqIT7JzpPmnu/sTCNGyZuuvXClo8tkRlhz5OvvwvFZgFcmPRloSa6 jBgW1SRGSmMuXMhcBPDszDRqJM1qdqA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=VMjUjDlz; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665707094; a=rsa-sha256; cv=none; b=7Mqn/WBECmIpIMIkk56dB8BWRhSEqepLIJ7qJh7o0V05c3wQBnBzp1b+sInYIvJaZ+5p9T d8she+qbAU6BcXyGDvr0xImwHBDf1SpA31E4a4ony6rVDyK6Ewi2HYUmhUMAFi1cBpMESo 78Wt4wD/OXwFFy9dUzUmzPu3XQ+EmMc= X-Rspam-User: X-Rspamd-Queue-Id: C79B218001F X-Stat-Signature: 37w7ng6s6o7dbyjqdq8jp86mt9ss1zm7 Authentication-Results: imf06.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=VMjUjDlz; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam10 X-HE-Tag: 1665707093-811255 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 10/13/22 12:48, Borislav Petkov wrote: >> It's planned to make this check part of an specification that can be >> passed to people purchasing hardware > How is that supposed to work? > > People would boot a Linux on that hardware and fwupd would tell them > whether it can encrypt memory or not? > > But if that were the only use case, why can't EFI simply say that in its > fancy GUI? > > Because all the kernel seems to be doing here is parrot further > EFI_MEMORY_CPU_CRYPTO. > > And that attribute gets set by EFI so it goes and picks apart whether > the underlying hw can encrypt memory. So EFI could report it too. I think the kernel _would_ just be parroting the firmware's info *if* this stuff was all static at boot. It pretty much _is_ static on today's systems. You generally can't hotplug memory (encrypted or not) on any of these fancy memory encryption systems. On the Intel side, I'm thinking mostly of Ice Lake systems. But, that is very much changing once CXL comes on the scene. A system might boot with only DRAM attached right to the CPU and all of it is encryption-capable. Then, some wise guys plugs in a CXL card that doesn't support encryption. That makes the "is everything encrypted" answer dynamic and is essentially unanswerable at boot, other than to give a one-off answer.