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 1255DC433F5 for ; Thu, 3 Feb 2022 16:43:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46BB16B03D9; Thu, 3 Feb 2022 11:43:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F49B6B03DA; Thu, 3 Feb 2022 11:43:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 247F56B03DB; Thu, 3 Feb 2022 11:43:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 1477F6B03D9 for ; Thu, 3 Feb 2022 11:43:48 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C4F8F9A26C for ; Thu, 3 Feb 2022 16:43:47 +0000 (UTC) X-FDA: 79102040094.17.FCC3EF8 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by imf05.hostedemail.com (Postfix) with ESMTP id 5270B100006 for ; Thu, 3 Feb 2022 16:43:47 +0000 (UTC) Received: by mail-oi1-f171.google.com with SMTP id q8so4916584oiw.7 for ; Thu, 03 Feb 2022 08:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=QmSfrWHOO84iaJyreyRK8M8+SfjOnwhXnoamUVhnFVM=; b=f1HPfVimFD2LZF1Lv4H8bnNprlEGted0B5APv+dH6dI4e6En6v9iU/qKC87lQF7OL6 vUeB3V5BqfhiVuS7SNo6YRY0C1ckL2SCQFbSexD9mZnwCb4QntyBRFtG1EDwuiYFB+7S Vql6hAwLAg/XxDA1dF4rji3yz+Ha+DhEo+WKd+qW6m2Vf7PMQDoTwecNBCY+pBoZrRza 36Nqtrnx9tVdba0bTzcmyETWSt05dtU1phg/Vg0kL5rNdHosWABja3G2Y5r5nqf9pfEV 9bT/pxBS5Wjc2GHR4Et/4nIgwQlI9m1xINpO79hPUlPA97f3NRLzGfhgoW4HnyIFXVOa wTCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=QmSfrWHOO84iaJyreyRK8M8+SfjOnwhXnoamUVhnFVM=; b=noy7cax6AdWiq8MpRj2CWVQ7j2LvJlMv1+hMMnSn2K9SG1bt0trfsZSuOst4twwPcl QPjrJE1bQ5QeOUt29thwzUeq38Fj+uXw6iFMg6ZqSBBMMsy0WxneQB0BOkSFROhDcHOl wmlzOHitHmUsjw9YJNXRA9RwVB7LTRZx9ufp29Sr4RNlon5svxvjQVL6o8ONw4a/3/Iq S2Va88+JIYPAp2Ha6gSOGxuGdOAE4je260BuuniG7JaDKR8WGXoPSUdp6Pa2xdT+9g8t 1dP78nLrgrH0ydwwvkYrpuo+F5VUfTvVdFvjkV+3oM4qR/DMDNlNHGVWljsAosg6yyfX GAAw== X-Gm-Message-State: AOAM531rqdKyiRFdWDv7OagVfBuoZ4U9S5DKri3VBVh376VHPX+xkrmI sV4fHwp+wETIrimom2CsTs5tbg== X-Google-Smtp-Source: ABdhPJyHt9krov7XOEQrs2XrKBepLYGKwwnCV87B2YLejYqTSyb4UBUr29AAuHXP3cehb+4vmGUQug== X-Received: by 2002:aca:bb83:: with SMTP id l125mr7554966oif.153.1643906626460; Thu, 03 Feb 2022 08:43:46 -0800 (PST) Received: from localhost (host8.190-224-49.telecom.net.ar. [190.224.49.8]) by smtp.gmail.com with ESMTPSA id cy22sm226253oab.17.2022.02.03.08.43.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Feb 2022 08:43:46 -0800 (PST) From: Martin Fernandez To: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, 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, Martin Fernandez Subject: [PATCH v6 0/6] x86: Show in sysfs if a memory node is able to do encryption Date: Thu, 3 Feb 2022 13:43:22 -0300 Message-Id: <20220203164328.203629-1-martin.fernandez@eclypsium.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5270B100006 X-Stat-Signature: hmrkxnfokwjibs6xrgjjs5f5k1y1ree8 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=eclypsium.com header.s=google header.b=f1HPfVim; dmarc=pass (policy=quarantine) header.from=eclypsium.com; spf=pass (imf05.hostedemail.com: domain of martin.fernandez@eclypsium.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=martin.fernandez@eclypsium.com X-Rspam-User: nil X-HE-Tag: 1643906627-119356 Content-Transfer-Encoding: quoted-printable 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: Show for each node if every memory descriptor in that node has the EFI_MEMORY_CPU_CRYPTO attribute. fwupd project plans to use it as part of a check to see if the users have properly configured memory hardware encryption capabilities. fwupd's people have seen cases where it seems like there is memory encryption because all the hardware is capable of doing it, but on a closer look there is not, either because of system firmware or because some component requires updating to enable the feature. It's planned to make it part of a specification that can be passed to people purchasing hardware These checks will run at every boot. The specification is called Host Security ID: https://fwupd.github.io/libfwupdplugin/hsi.html. We choosed to do it a per-node basis because although an ABI that shows that the whole system memory is capable of encryption would be useful for the fwupd use case, doing it in a per-node basis gives also the capability to the user to target allocations from applications to NUMA nodes which have encryption capabilities. Changes since v5: Refactor e820__range_{update, remove, set_crypto_capable} in order to avoid code duplication. Warn the user when a node has both encryptable and non-encryptable regions. Check that e820_table has enough size to store both current e820_table and EFI memmap. Changes since v4: Add enum to represent the cryptographic capabilities in e820: e820_crypto_capabilities. Revert __e820__range_update, only adding the new argument for __e820__range_add about crypto capabilities. Add a function __e820__range_update_crypto similar to __e820__range_update but to only update this new field. Changes since v3: Update date in Doc/ABI file. More information about the fwupd usecase and the rationale behind doing it in a per-NUMA-node. Changes since v2: e820__range_mark_crypto -> e820__range_mark_crypto_capable. In e820__range_remove: Create a region with crypto capabilities instead of creating one without it and then mark it. Changes since v1: Modify __e820__range_update to update the crypto capabilities of a range; now this function will change the crypto capability of a range if it's called with the same old_type and new_type. Rework efi_mark_e820_regions_as_crypto_capable based on this. Update do_add_efi_memmap to mark the regions as it creates them. Change the type of crypto_capable in e820_entry from bool to u8. Fix e820__update_table changes. Remove memblock_add_crypto_capable. Now you have to add the region and mark it then. Better place for crypto_capable in pglist_data. Martin Fernandez (6): mm/memblock: Tag memblocks with crypto capabilities mm/mmzone: Tag pg_data_t with crypto capabilities x86/e820: Refactor range_update and range_remove x86/e820: Tag e820_entry with crypto capabilities x86/efi: Tag e820_entries as crypto capable from EFI memmap drivers/node: Show in sysfs node's crypto capabilities Documentation/ABI/testing/sysfs-devices-node | 10 + arch/x86/include/asm/e820/api.h | 1 + arch/x86/include/asm/e820/types.h | 12 +- arch/x86/kernel/e820.c | 485 +++++++++++++++---- arch/x86/platform/efi/efi.c | 37 ++ drivers/base/node.c | 10 + include/linux/memblock.h | 15 +- include/linux/mmzone.h | 3 + mm/memblock.c | 64 +++ mm/page_alloc.c | 1 + 10 files changed, 531 insertions(+), 107 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-node --=20 2.30.2