[PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Martin Fernandez]

Show for each NUMA node the value of EFI_MEMORY_CPU_CRYPTO in its
memory.

This is a serie of patches for exporting the needed information to
userspace to determine if a machine is using Intel's TME or MKTME.

In a next patch I'm going to export if TME/MKTME is activated by the
BIOS to sysfs, since right now for the user, this information is only
available in the kernel logs, and it's not appropriate for fwupd to
scan the boot logs just to parse an integer. I'm looking for
suggestions for where to store this value.

Changelog v2:

The value shown in each node now only corresponds to memory in that
node in particular

Martin Fernandez (5):
  Extend memblock to support memory encryption
  Extend pg_data_t to hold information about memory encryption
  Extend e820_table to hold information about memory encryption
  Mark e820_entries as crypto capable from EFI memmap
  Show in sysfs if a memory node is able to do memory encryption

 Documentation/ABI/testing/sysfs-devices-node |  12 +++
 arch/x86/include/asm/e820/api.h              |   2 +
 arch/x86/include/asm/e820/types.h            |   1 +
 arch/x86/include/asm/numa.h                  |   7 ++
 arch/x86/kernel/e820.c                       |  32 +++++-
 arch/x86/mm/numa.c                           |   5 +
 arch/x86/mm/numa_emulation.c                 |   2 +-
 arch/x86/platform/efi/efi.c                  | 108 +++++++++++++++++++
 drivers/base/node.c                          |  72 ++++++++++++-
 include/linux/memblock.h                     |   6 ++
 include/linux/mmzone.h                       |   2 +
 include/linux/node.h                         |   1 +
 mm/memblock.c                                |  74 +++++++++++++
 mm/page_alloc.c                              |   1 +
 14 files changed, 321 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-node


base-commit: 3906fe9bb7f1a2c8667ae54e967dc8690824f4ea
--
2.30.2

[PATCH v2 1/5] Extend memblock to support memory encryption

[Martin Fernandez]

Add the capability to mark regions of the memory memory_type able of
hardware memory encryption.

Also add the capability to query if all regions of a memory node are
able to do hardware memory encryption.

Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
---
 include/linux/memblock.h |  6 ++++
 mm/memblock.c            | 74 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 34de69b3b8ba..945af2cc7966 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -31,6 +31,7 @@ extern unsigned long long max_possible_pfn;
  * @MEMBLOCK_HOTPLUG: hotpluggable region
  * @MEMBLOCK_MIRROR: mirrored region
  * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
+ * @MEMBLOCK_CRYPTO_CAPABLE: capable of hardware encryption
  * reserved in the memory map; refer to memblock_mark_nomap() description
  * for further details
  */
@@ -39,6 +40,7 @@ enum memblock_flags {
 	MEMBLOCK_HOTPLUG	= 0x1,	/* hotpluggable region */
 	MEMBLOCK_MIRROR		= 0x2,	/* mirrored region */
 	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
+	MEMBLOCK_CRYPTO_CAPABLE = 0x8,  /* capable of hardware encryption */
 };
 
 /**
@@ -102,6 +104,7 @@ static inline void memblock_discard(void) {}
 void memblock_allow_resize(void);
 int memblock_add_node(phys_addr_t base, phys_addr_t size, int nid);
 int memblock_add(phys_addr_t base, phys_addr_t size);
+int memblock_add_crypto_capable(phys_addr_t base, phys_addr_t size);
 int memblock_remove(phys_addr_t base, phys_addr_t size);
 int memblock_free(phys_addr_t base, phys_addr_t size);
 int memblock_reserve(phys_addr_t base, phys_addr_t size);
@@ -111,6 +114,9 @@ int memblock_physmem_add(phys_addr_t base, phys_addr_t size);
 void memblock_trim_memory(phys_addr_t align);
 bool memblock_overlaps_region(struct memblock_type *type,
 			      phys_addr_t base, phys_addr_t size);
+bool memblock_node_is_crypto_capable(int nid);
+int memblock_mark_crypto_capable(phys_addr_t base, phys_addr_t size);
+int memblock_clear_crypto_capable(phys_addr_t base, phys_addr_t size);
 int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
 int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
 int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 5096500b2647..805e0e43ec66 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -191,6 +191,27 @@ bool __init_memblock memblock_overlaps_region(struct memblock_type *type,
 	return i < type->cnt;
 }
 
+/**
+ * memblock_node_is_crypto_capable - get if whole node is capable
+ * of encryption
+ * @nid: number of node
+ *
+ * Iterate over all memory memblock_type and find if all regions under
+ * node @nid are capable of hardware encryption.
+ */
+bool __init_memblock memblock_node_is_crypto_capable(int nid)
+{
+	struct memblock_region *region;
+
+	for_each_mem_region(region) {
+		if ((memblock_get_region_node(region) == nid) &&
+		    !(region->flags & MEMBLOCK_CRYPTO_CAPABLE))
+			return false;
+	}
+
+	return true;
+}
+
 /**
  * __memblock_find_range_bottom_up - find free area utility in bottom-up
  * @start: start of candidate range
@@ -694,6 +715,31 @@ int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
 	return memblock_add_range(&memblock.memory, base, size, MAX_NUMNODES, 0);
 }
 
+/**
+ * memblock_add_crypto_capable - add new memblock region capable of
+ * hardware encryption
+ * @base: base address of the new region
+ * @size: size of the new region
+ *
+ * Add new memblock region [@base, @base + @size) to the "memory" type
+ * and set the MEMBLOCK_CRYPTO_CAPABLE flag. See memblock_add_range()
+ * description for mode details
+ *
+ * Return:
+ * 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_add_crypto_capable(phys_addr_t base,
+						phys_addr_t size)
+{
+	const phys_addr_t end = base + size - 1;
+
+	memblock_dbg("%s: [%pa-%pa] %pS\n", __func__,
+		     &base, &end, (void *)_RET_IP_);
+
+	return memblock_add_range(&memblock.memory, base, size, MAX_NUMNODES,
+				  MEMBLOCK_CRYPTO_CAPABLE);
+}
+
 /**
  * memblock_isolate_range - isolate given range into disjoint memblocks
  * @type: memblock type to isolate range for
@@ -884,6 +930,34 @@ static int __init_memblock memblock_setclr_flag(phys_addr_t base,
 	return 0;
 }
 
+/**
+ * memblock_mark_crypto_capable - Mark memory regions capable of hardware
+ * encryption with flag MEMBLOCK_CRYPTO_CAPABLE.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_mark_crypto_capable(phys_addr_t base,
+						 phys_addr_t size)
+{
+	return memblock_setclr_flag(base, size, 1, MEMBLOCK_CRYPTO_CAPABLE);
+}
+
+/**
+ * memblock_clear_crypto_capable - Clear flag MEMBLOCK_CRYPTO for a
+ * specified region.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_clear_crypto_capable(phys_addr_t base,
+						  phys_addr_t size)
+{
+	return memblock_setclr_flag(base, size, 0, MEMBLOCK_CRYPTO_CAPABLE);
+}
+
 /**
  * memblock_mark_hotplug - Mark hotpluggable memory with flag MEMBLOCK_HOTPLUG.
  * @base: the base phys addr of the region
-- 
2.30.2

[PATCH v2 2/5] Extend pg_data_t to hold information about memory encryption

[Martin Fernandez]

Add a new member in the pg_data_t struct tell whether the node
corresponding to that pg_data_t is able to do hardware memory encryption.

Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
---
 include/linux/mmzone.h | 2 ++
 mm/page_alloc.c        | 1 +
 2 files changed, 3 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 6a1d79d84675..998fbe371a81 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -869,6 +869,8 @@ typedef struct pglist_data {
 	unsigned long		min_slab_pages;
 #endif /* CONFIG_NUMA */
 
+	bool crypto_capable;
+
 	/* Write-intensive fields used by page reclaim */
 	ZONE_PADDING(_pad1_)
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b37435c274cf..a19d95bb5c0f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7575,6 +7575,7 @@ static void __init free_area_init_node(int nid)
 	pgdat->node_id = nid;
 	pgdat->node_start_pfn = start_pfn;
 	pgdat->per_cpu_nodestats = NULL;
+	pgdat->crypto_capable = memblock_node_is_crypto_capable(nid);
 
 	pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid,
 		(u64)start_pfn << PAGE_SHIFT,
-- 
2.30.2

[PATCH v2 3/5] Extend e820_table to hold information about memory encryption

[Martin Fernandez]

Add a new member in e820_entry to hold whether an entry is able to do
hardware memory encryption or not.

Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
---
 arch/x86/include/asm/e820/api.h   |  2 ++
 arch/x86/include/asm/e820/types.h |  1 +
 arch/x86/kernel/e820.c            | 32 +++++++++++++++++++++++++++++--
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index e8f58ddd06d9..f3a09b6afca1 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -18,6 +18,8 @@ extern void e820__range_add   (u64 start, u64 size, enum e820_type type);
 extern u64  e820__range_update(u64 start, u64 size, enum e820_type old_type, enum e820_type new_type);
 extern u64  e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type);
 
+extern void e820__mark_regions_as_crypto_capable(u64 start, u64 size);
+
 extern void e820__print_table(char *who);
 extern int  e820__update_table(struct e820_table *table);
 extern void e820__update_table_print(void);
diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/types.h
index 314f75d886d0..231c9ad9a9c3 100644
--- a/arch/x86/include/asm/e820/types.h
+++ b/arch/x86/include/asm/e820/types.h
@@ -56,6 +56,7 @@ struct e820_entry {
 	u64			addr;
 	u64			size;
 	enum e820_type		type;
+	bool			crypto_capable;
 } __attribute__((packed));
 
 /*
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index bc0657f0deed..3e0aaa5525e0 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -176,6 +176,7 @@ static void __init __e820__range_add(struct e820_table *table, u64 start, u64 si
 	table->entries[x].addr = start;
 	table->entries[x].size = size;
 	table->entries[x].type = type;
+	table->entries[x].crypto_capable = false;
 	table->nr_entries++;
 }
 
@@ -184,6 +185,19 @@ void __init e820__range_add(u64 start, u64 size, enum e820_type type)
 	__e820__range_add(e820_table, start, size, type);
 }
 
+void __init e820__mark_regions_as_crypto_capable(u64 start, u64 size)
+{
+	int i;
+	u64 end = start + size;
+
+	for (i = 0; i < e820_table->nr_entries; i++) {
+		struct e820_entry *const entry = &e820_table->entries[i];
+
+		if (entry->addr >= start && entry->addr + entry->size <= end)
+			entry->crypto_capable = true;
+	}
+}
+
 static void __init e820_print_type(enum e820_type type)
 {
 	switch (type) {
@@ -211,6 +225,8 @@ void __init e820__print_table(char *who)
 			e820_table->entries[i].addr + e820_table->entries[i].size - 1);
 
 		e820_print_type(e820_table->entries[i].type);
+		pr_cont("%s",
+			e820_table->entries[i].crypto_capable ? "; crypto-capable" : "");
 		pr_cont("\n");
 	}
 }
@@ -327,6 +343,8 @@ int __init e820__update_table(struct e820_table *table)
 	unsigned long long last_addr;
 	u32 new_nr_entries, overlap_entries;
 	u32 i, chg_idx, chg_nr;
+	bool current_crypto;
+	bool last_crypto = false;
 
 	/* If there's only one memory region, don't bother: */
 	if (table->nr_entries < 2)
@@ -388,13 +406,17 @@ int __init e820__update_table(struct e820_table *table)
 		 * 1=usable, 2,3,4,4+=unusable)
 		 */
 		current_type = 0;
+		current_crypto = false;
 		for (i = 0; i < overlap_entries; i++) {
+			current_crypto = current_crypto || overlap_list[i]->crypto_capable;
 			if (overlap_list[i]->type > current_type)
 				current_type = overlap_list[i]->type;
 		}
 
 		/* Continue building up new map based on this information: */
-		if (current_type != last_type || e820_nomerge(current_type)) {
+		if (current_type != last_type ||
+		    current_crypto != last_crypto ||
+		    e820_nomerge(current_type)) {
 			if (last_type != 0)	 {
 				new_entries[new_nr_entries].size = change_point[chg_idx]->addr - last_addr;
 				/* Move forward only if the new size was non-zero: */
@@ -406,6 +428,9 @@ int __init e820__update_table(struct e820_table *table)
 			if (current_type != 0)	{
 				new_entries[new_nr_entries].addr = change_point[chg_idx]->addr;
 				new_entries[new_nr_entries].type = current_type;
+				new_entries[new_nr_entries].crypto_capable = current_crypto;
+
+				last_crypto = current_crypto;
 				last_addr = change_point[chg_idx]->addr;
 			}
 			last_type = current_type;
@@ -1321,7 +1346,10 @@ void __init e820__memblock_setup(void)
 		if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN)
 			continue;
 
-		memblock_add(entry->addr, entry->size);
+		if (entry->crypto_capable)
+			memblock_add_crypto_capable(entry->addr, entry->size);
+		else
+			memblock_add(entry->addr, entry->size);
 	}
 
 	/* Throw away partial pages: */
-- 
2.30.2

[PATCH v2 4/5] Mark e820_entries as crypto capable from EFI memmap

[Martin Fernandez]

Iterate over the EFI memmap finding the contiguous regions that are
able to do hardware encryption (ie, those who have the
EFI_MEMORY_CPU_CRYPTO enabled) and mark those in the e820_table.

Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
---
 arch/x86/platform/efi/efi.c | 109 ++++++++++++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 147c30a81f15..6cd1c11dbdad 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -441,6 +441,113 @@ static int __init efi_config_init(const efi_config_table_type_t *arch_tables)
 	return ret;
 }
 
+/*
+ * The contiguous_region type is used to help
+ * efi_mark_e820_regions_as_crypto_capable to pick all the contiguous
+ * regions that have the EFI_MEMORY_CPU_CRYPTO attribute, and call a
+ * function of the e820 module to mark those regions as being able to
+ * do hardware encryption.
+ *
+ * To use this properly the memory map must not have any overlapped
+ * regions and the regions should be sorted.
+ *
+ * cr in the function names stands for contiguous_region
+ */
+struct contiguous_region {
+	u64 start;
+	u64 end;
+};
+
+static void __init cr_init(struct contiguous_region *region)
+{
+	region->start = 0;
+	region->end = 0;
+}
+
+static void __init efi_md_to_cr(const efi_memory_desc_t *md,
+				struct contiguous_region *region)
+{
+	region->start = md->phys_addr;
+	region->end = md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1;
+}
+
+static u64 __init cr_size(const struct contiguous_region *r)
+{
+	return r->end - r->start + 1;
+}
+
+static bool __init cr_is_empty(const struct contiguous_region *r)
+{
+	/*
+	 * Since contiguous regions are built upon efi_memory_desc_t
+	 * it is safe to say that a region is empty if its size is
+	 * lower than the size of one EFI page.
+	 */
+	return cr_size(r) < (1 << EFI_PAGE_SHIFT);
+}
+
+static bool __init cr_merge_regions(struct contiguous_region *region1,
+				    const struct contiguous_region *region2)
+{
+	bool merged_result;
+
+	if (cr_is_empty(region1)) {
+		*region1 = *region2;
+		merged_result = true;
+	} else if (region1->end + 1 == region2->start) {
+		/* Extend region1 */
+		region1->end = region2->end;
+		merged_result = true;
+	} else {
+		merged_result = false;
+	}
+
+	return merged_result;
+}
+
+static void __init cr_mark_e820_as_crypto_capable(const struct contiguous_region *r)
+{
+	e820__mark_regions_as_crypto_capable(r->start, cr_size(r));
+}
+
+/*
+ * This assumes that there'll be no overlaps in the memory map
+ * (otherwise we'd have a deeper problem going on). It also assumes
+ * that the system DRAM regions are already sorted; in EDK2 based UEFI
+ * firmware the entries covering system DRAM are usually sorted, with
+ * additional MMIO entries appearing unordered. This is because the
+ * UEFI memory map is constructed from the GCD memory map, which is
+ * seeded with the DRAM regions at boot, and allocations are created
+ * by splitting them up.
+ */
+static void __init efi_mark_e820_regions_as_crypto_capable(void)
+{
+	efi_memory_desc_t *md;
+	struct contiguous_region prev_region;
+
+	cr_init(&prev_region);
+
+	for_each_efi_memory_desc(md) {
+		if (md->attribute & EFI_MEMORY_CPU_CRYPTO) {
+			struct contiguous_region cur_region;
+
+			efi_md_to_cr(md, &cur_region);
+
+			if (!cr_merge_regions(&prev_region, &cur_region)) {
+				cr_mark_e820_as_crypto_capable(&prev_region);
+				prev_region = cur_region;
+			} /* else: Merge succeeded, don't mark yet */
+		} else if (!cr_is_empty(&prev_region)) {
+			cr_mark_e820_as_crypto_capable(&prev_region);
+			cr_init(&prev_region);
+		} /* else: All previous regions are already marked */
+	}
+
+	/* Mark last region (if any) */
+	if (!cr_is_empty(&prev_region))
+		cr_mark_e820_as_crypto_capable(&prev_region);
+}
+
 void __init efi_init(void)
 {
 	if (IS_ENABLED(CONFIG_X86_32) &&
@@ -494,6 +601,8 @@ void __init efi_init(void)
 	set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 	efi_clean_memmap();
 
+	efi_mark_e820_regions_as_crypto_capable();
+
 	if (efi_enabled(EFI_DBG))
 		efi_print_memmap();
 }
-- 
2.30.2

[PATCH v2 5/5] Show in sysfs if a memory node is able to do memory encryption

[Martin Fernandez]

Show in each node in sysfs if its memory is able to do hardware memory
encryption, ie. if all its memory is marked with EFI_MEMORY_CPU_CRYPTO
in the EFI memory map.

This value will only be shown if the memory is local to at least one
CPU, since otherwise it won't be able to be encrypted by CPU's
cryptographic capabilities. This check is done against the ACPI's SRAT
table.

Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com>
---
 Documentation/ABI/testing/sysfs-devices-node | 12 ++++
 arch/x86/include/asm/numa.h                  |  7 ++
 arch/x86/mm/numa.c                           |  5 ++
 arch/x86/mm/numa_emulation.c                 |  2 +-
 drivers/base/node.c                          | 72 +++++++++++++++++++-
 include/linux/node.h                         |  1 +
 6 files changed, 97 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-node

diff --git a/Documentation/ABI/testing/sysfs-devices-node b/Documentation/ABI/testing/sysfs-devices-node
new file mode 100644
index 000000000000..313fc4193977
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-node
@@ -0,0 +1,12 @@
+What:		/sys/devices/system/node/nodeX/crypto_capable
+Date:		October 2021
+Contact:	Martin Fernandez <martin.fernandez@eclypsium.com>
+Users:		fwupd
+Description:
+		This value is 1 if all system memory in this node is
+		marked with EFI_MEMORY_CPU_CRYPTO, indicating that the
+		system memory is capable of being protected with the
+		CPU’s memory cryptographic capabilities. It is 0
+		otherwise. This attribute will only be available if
+		node X is in ACPI's SRAT table or if it is an emulated
+		node.
diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index e3bae2b60a0d..c3ed5c5be885 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86/include/asm/numa.h
@@ -20,6 +20,13 @@
 #define NODE_MIN_SIZE (4*1024*1024)
 
 extern int numa_off;
+extern int emu_nid_to_phys[];
+
+/*
+ * used_dummy_numa_init indicates whether we used dummy_numa_init for
+ * initialization or not
+ */
+extern bool used_dummy_numa_init;
 
 /*
  * __apicid_to_node[] stores the raw mapping between physical apicid and
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 1e9b93b088db..f8d3a0d6bee1 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -20,6 +20,7 @@
 #include "numa_internal.h"
 
 int numa_off;
+bool used_dummy_numa_init;
 nodemask_t numa_nodes_parsed __initdata;
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
@@ -712,6 +713,8 @@ static int __init dummy_numa_init(void)
 	node_set(0, numa_nodes_parsed);
 	numa_add_memblk(0, 0, PFN_PHYS(max_pfn));
 
+	used_dummy_numa_init = true;
+
 	return 0;
 }
 
@@ -724,6 +727,8 @@ static int __init dummy_numa_init(void)
  */
 void __init x86_numa_init(void)
 {
+	used_dummy_numa_init = false;
+
 	if (!numa_off) {
 #ifdef CONFIG_ACPI_NUMA
 		if (!numa_init(x86_acpi_numa_init))
diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
index e801e30089c4..f45bc30698e7 100644
--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -10,7 +10,7 @@
 
 #include "numa_internal.h"
 
-static int emu_nid_to_phys[MAX_NUMNODES];
+int emu_nid_to_phys[MAX_NUMNODES];
 static char *emu_cmdline __initdata;
 
 int __init numa_emu_cmdline(char *str)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index c56d34f8158f..b2e1a8832fcf 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -5,6 +5,7 @@
 
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/acpi.h>
 #include <linux/mm.h>
 #include <linux/memory.h>
 #include <linux/vmstat.h>
@@ -560,11 +561,39 @@ static ssize_t node_read_distance(struct device *dev,
 }
 static DEVICE_ATTR(distance, 0444, node_read_distance, NULL);
 
+static ssize_t crypto_capable_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct pglist_data *pgdat = NODE_DATA(dev->id);
+
+	return sysfs_emit(buf, "%d\n", pgdat->crypto_capable);
+}
+static DEVICE_ATTR_RO(crypto_capable);
+
+static umode_t node_attr_is_visible(struct kobject *kobj,
+				    struct attribute *attr, int n)
+{
+	umode_t result = 0;
+
+	if (attr == &dev_attr_crypto_capable.attr) {
+		const struct device *const dev =
+			container_of(kobj, struct device, kobj);
+		const int nid = dev->id;
+
+		if (node_devices[nid]->cpu_local)
+			result = attr->mode;
+		/* else: hide the attribute */
+	}
+
+	return result;
+}
+
 static struct attribute *node_dev_attrs[] = {
 	&dev_attr_meminfo.attr,
 	&dev_attr_numastat.attr,
 	&dev_attr_distance.attr,
 	&dev_attr_vmstat.attr,
+	&dev_attr_crypto_capable.attr,
 	NULL
 };
 
@@ -576,7 +605,8 @@ static struct bin_attribute *node_dev_bin_attrs[] = {
 
 static const struct attribute_group node_dev_group = {
 	.attrs = node_dev_attrs,
-	.bin_attrs = node_dev_bin_attrs
+	.bin_attrs = node_dev_bin_attrs,
+	.is_visible = node_attr_is_visible,
 };
 
 static const struct attribute_group *node_dev_groups[] = {
@@ -972,6 +1002,44 @@ static void init_node_hugetlb_work(int nid) { }
 
 #endif
 
+#ifdef CONFIG_NUMA
+#ifdef CONFIG_NUMA_EMU
+static int get_real_nid(int nid)
+{
+	return emu_nid_to_phys[nid];
+}
+#else
+static int get_real_nid(int nid)
+{
+	return nid;
+}
+#endif /* CONFIG_NUMA_EMU */
+
+static void set_cpu_local(int nid)
+{
+	const int real_nid = get_real_nid(nid);
+	bool cpu_local;
+
+	/*
+	 * If we have the SRAT table available we need to check it
+	 * otherwise it's enough to check if real_nid is 0
+	 */
+#ifdef CONFIG_ACPI_NUMA
+	cpu_local =
+		used_dummy_numa_init ? real_nid == 0 : node_to_pxm(real_nid) != PXM_INVAL;
+#else
+	cpu_local = real_nid == 0;
+#endif
+
+	node_devices[nid]->cpu_local = cpu_local;
+}
+#else
+static void set_cpu_local(nid)
+{
+	node_devices[nid]->cpu_local = true;
+}
+#endif /* CONFIG_NUMA */
+
 int __register_one_node(int nid)
 {
 	int error;
@@ -981,6 +1049,8 @@ int __register_one_node(int nid)
 	if (!node_devices[nid])
 		return -ENOMEM;
 
+	set_cpu_local(nid);
+
 	error = register_node(node_devices[nid], nid);
 
 	/* link cpu under this node */
diff --git a/include/linux/node.h b/include/linux/node.h
index 8e5a29897936..d32653fac39e 100644
--- a/include/linux/node.h
+++ b/include/linux/node.h
@@ -92,6 +92,7 @@ struct node {
 	struct list_head cache_attrs;
 	struct device *cache_dev;
 #endif
+	bool cpu_local;
 };
 
 struct memory_block;
-- 
2.30.2

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Dave Hansen]

On 10/27/21 12:55 PM, Martin Fernandez wrote:
> This is a serie of patches for exporting the needed information to
> userspace to determine if a machine is using Intel's TME or MKTME.
> 
> In a next patch I'm going to export if TME/MKTME is activated by the
> BIOS to sysfs, since right now for the user, this information is only
> available in the kernel logs, and it's not appropriate for fwupd to
> scan the boot logs just to parse an integer. I'm looking for
> suggestions for where to store this value.

I didn't see any TME or MKTME-specific stuff in these patches.  Are you
assuming that all systems with any MEMBLOCK_CRYPTO_CAPABLE regions have
TME activated?

This also doesn't mention how userspace plans to *use* this information.
 I think you mentioned it before, but it needs to be in the cover letter
and changelogs too.

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Martin Fernandez]

On 10/27/21, Dave Hansen <dave.hansen@intel.com> wrote:
> On 10/27/21 12:55 PM, Martin Fernandez wrote:
>> This is a serie of patches for exporting the needed information to
>> userspace to determine if a machine is using Intel's TME or MKTME.
>>
>> In a next patch I'm going to export if TME/MKTME is activated by the
>> BIOS to sysfs, since right now for the user, this information is only
>> available in the kernel logs, and it's not appropriate for fwupd to
>> scan the boot logs just to parse an integer. I'm looking for
>> suggestions for where to store this value.
>
> I didn't see any TME or MKTME-specific stuff in these patches.  Are you
> assuming that all systems with any MEMBLOCK_CRYPTO_CAPABLE regions have
> TME activated?

Yes, you are correct, I didn't do anything TME-specific. That's the
part that I still need to do, I'm planning to do something similar to
detect_tme in /arch/x86/kernel/cpu/intel.c, but showing "TME" or
"MKTME" somewhere in sysfs, don't know where. Maybe in securityfs? And
it can also show the AMD variants in the future.

And no, I'm assuming that MEMBLOCK_CRYPTO_CAPABLE implies TME
activated, it's just another check to secure that the memory is
actually being encrypted.

> This also doesn't mention how userspace plans to *use* this information.
>  I think you mentioned it before, but it needs to be in the cover letter
> and changelogs too.
>

Userspace will just read this values and conclude (as it is right now)
if your memory is able to do encryption. As I mentioned above, with
the TME part, you will conclude if your memory is being encrypted or
not, and if not, you can see why not. For example, if you have TME,
you have it enabled but you have crypto_capable = 0 in your nodes,
then you probably have an old BIOS that doesn't support UEFI 2.7, and
that's why you don't have your memory flagged with
EFI_MEMORY_CPU_CRYPTO. And then you can tell to the user that maybe a
BIOS update will fix that.

That's what fwupd will try to do.

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Borislav Petkov]

On Thu, Oct 28, 2021 at 11:28:57AM -0300, Martin Fernandez wrote:
> Userspace will just read this values and conclude (as it is right now)
> if your memory is able to do encryption.

And do what with that information?

> As I mentioned above, with the TME part, you will conclude if your
> memory is being encrypted or not, and if not, you can see why not.
> For example, if you have TME, you have it enabled but you have
> crypto_capable = 0 in your nodes, then you probably have an old BIOS
> that doesn't support UEFI 2.7, and that's why you don't have your
> memory flagged with EFI_MEMORY_CPU_CRYPTO. And then you can tell to
> the user that maybe a BIOS update will fix that.

If it is all about dumping this new EFI_MEMORY_CPU_CRYPTO
attribute for each region, you can extend efi_print_memmap() and
efi_md_typeattr_format() to show that in dmesg and not add a bunch of
code to the kernel.

If you wanna query encryption status, we have flags in /proc/cpuinfo for
that and we can add more if needed.

The stress being on "if" because from all this intro text I cannot find
a single persuasive use case.

So what is the real-life use case?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Dave Hansen]

On 10/28/21 7:28 AM, Martin Fernandez wrote:
> Userspace will just read this values and conclude (as it is right now)
> if your memory is able to do encryption. As I mentioned above, with
> the TME part, you will conclude if your memory is being encrypted or
> not, and if not, you can see why not. For example, if you have TME,
> you have it enabled but you have crypto_capable = 0 in your nodes,
> then you probably have an old BIOS that doesn't support UEFI 2.7, and
> that's why you don't have your memory flagged with
> EFI_MEMORY_CPU_CRYPTO. And then you can tell to the user that maybe a
> BIOS update will fix that.
> 
> That's what fwupd will try to do.

Is it worth a new kernel ABI to give userspace a "maybe" signal?

I'm leaning towards no.

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Richard Hughes]

On Thu, 28 Oct 2021 at 15:55, Borislav Petkov <bp@alien8.de> wrote:
> > Userspace will just read this values and conclude (as it is right now)
> > if your memory is able to do encryption.
> And do what with that information?

We've got Red Hat customers right now that are completely confused if
they have hardware capable of encrypted memory. We want to make it
part of a specification that can be passed to the people actually
purchasing the hardware.

Richard

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Borislav Petkov]

On Thu, Oct 28, 2021 at 05:03:20PM +0100, Richard Hughes wrote:
> We've got Red Hat customers right now that are completely confused if
> they have hardware capable of encrypted memory. We want to make it
> part of a specification that can be passed to the people actually
> purchasing the hardware.

Sorry, you need to expand on that: part of what specification? How is
this going to be run? How is the customer supposed to figure that out
when she has the hardware?

Why cannot this be a userspace program, script, tool, whatever?

My questions are still unanswered.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Martin Fernandez]

On 10/28/21, Borislav Petkov <bp@alien8.de> wrote:
> Why cannot this be a userspace program, script, tool, whatever?

Because it's not convenient to parse dmesg. And about /proc/cpuinfo,
it tells you about TME, as a feature of the cpu but it doesn't tell
you if it is activated, and even if it is activated you will need to
be sure that you are storing your data in a region flagged with this
new attribute.

Here we discussed about it some time ago:
http://lkml.iu.edu/hypermail/linux/kernel/2006.2/06753.html . That
comment is what triggered this patch.

Re: [PATCH v2 5/5] Show in sysfs if a memory node is able to do memory encryption

[Dave Hansen]

On 10/27/21 12:55 PM, Martin Fernandez wrote:
> This value will only be shown if the memory is local to at least one
> CPU, since otherwise it won't be able to be encrypted by CPU's
> cryptographic capabilities. This check is done against the ACPI's SRAT
> table.

What does "local to at least one CPU" mean?  I can't even make sense of
what the code is trying to do (which is a whole separate issue).

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Borislav Petkov]

On Thu, Oct 28, 2021 at 02:39:52PM -0300, Martin Fernandez wrote:
> Because it's not convenient to parse dmesg. And about /proc/cpuinfo,
> it tells you about TME, as a feature of the cpu but it doesn't tell
> you if it is activated,

We can make "tme" or whatever string we decide upon, visible only when
the feature is activated - not a problem. Just like we do on AMD.

> and even if it is activated you will need to be sure that you are
> storing your data in a region flagged with this new attribute.

Can you have a system where some of the memory is crypto-capable and
some of it is not? I've never heard about such a system. At least, on
AMD SME, all your memory gets encrypted...

> Here we discussed about it some time ago:
> http://lkml.iu.edu/hypermail/linux/kernel/2006.2/06753.html . That
> comment is what triggered this patch.

... or maybe dhansen knows more.

So, you folks feeding us piecemeal all these "requirements" won't get
you very far. So please sit down and write a detailed use case about
which customers, when and what exactly they need extracted from the
system and why.

Because this is not all - there's TDX and SEV and SEV-ES and SEV-SNP and
all those partition and encrypt the system or part of it in a different
way. And I'm sure customers will wanna know about that too. Are they
running in an encrypted guest in a public cloud, what security they
have, blabla, everything you can imagine.

And so we won't be adding a different reporting method for each type of
encryption that happens.

But we don't know what we need to report unless we know the use case.
Which is not in the least clear to me.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Dave Hansen]

On 10/28/21 11:10 AM, Borislav Petkov wrote:
>> and even if it is activated you will need to be sure that you are
>> storing your data in a region flagged with this new attribute.
> Can you have a system where some of the memory is crypto-capable and
> some of it is not? I've never heard about such a system. At least, on
> AMD SME, all your memory gets encrypted...

Yes, unfortunately.

As an example, an Intel system with TME support will *not* encrypt data
going to Optane (aka. pmem).  That pmem might be online and being used
by the kernel as normal RAM with my fancy "kmem" DAX driver.

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.

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Richard Hughes]

On Thu, 28 Oct 2021 at 17:35, Borislav Petkov <bp@alien8.de> wrote:
> Sorry, you need to expand on that: part of what specification?

My apologies, I should have linked to the specification. It's called
Host Security ID: https://fwupd.github.io/libfwupdplugin/hsi.html

> How is this going to be run?

HSI tests are run at every boot and logged. HSI is part of Insights
(for servers) and is even now part of several large companies'
purchasing policies.

> Why cannot this be a userspace program, script, tool, whatever?

We actually tried this, using the journal API:
https://github.com/fwupd/fwupd/pull/2129

It was a hack, and took a really long time to complete on slow
embedded hardware.

Richard

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Dave Hansen]

On 10/28/21 10:39 AM, Martin Fernandez wrote:
> On 10/28/21, Borislav Petkov <bp@alien8.de> wrote:
>> Why cannot this be a userspace program, script, tool, whatever?
> Because it's not convenient to parse dmesg. And about /proc/cpuinfo,
> it tells you about TME, as a feature of the cpu but it doesn't tell
> you if it is activated, and even if it is activated you will need to
> be sure that you are storing your data in a region flagged with this
> new attribute.
> 
> Here we discussed about it some time ago:
> http://lkml.iu.edu/hypermail/linux/kernel/2006.2/06753.html . That
> comment is what triggered this patch.

Martin,

I don't think this interface makes any sense at all for something off of
which to base firmware updates.  It's just too noisy.

That said, I *do* think we are going to need something similar to what
you propose here because folks are going to want to target memory
allocations to NUMA nodes that have encryption capabilities.

But, I don't think what you've proposed here fits very well there.  The
->cpu_local thing looks totally broken.  It's entirely unclear what
users are supposed to do when the crypto_capable file is not present.

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Martin Fernandez]

On 10/29/21, Dave Hansen <dave.hansen@intel.com> wrote:
> But, I don't think what you've proposed here fits very well there.  The
> ->cpu_local thing looks totally broken.  It's entirely unclear what
> users are supposed to do when the crypto_capable file is not present.
>

Yes, I apologize, it was a misunderstanding between myself and the
team that reviewing the patch before it was sent. The idea behind that
code was to do another thing that we decided to drop. The final
version should have this file for every node in the system.

Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

[Martin Fernandez]

On 10/29/21, Dave Hansen <dave.hansen@intel.com> wrote:
> I don't think this interface makes any sense at all for something off of
> which to base firmware updates.  It's just too noisy.
>
> That said, I *do* think we are going to need something similar to what
> you propose here because folks are going to want to target memory
> allocations to NUMA nodes that have encryption capabilities.

And how do think we should approach this? Putting apart the TME part,
ie, this patch as it is (but showing the file for every node), what do
think it's the next step?