From: "Williams, Dan J" <dan.j.williams@intel.com>
To: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"martin.fernandez@eclypsium.com" <martin.fernandez@eclypsium.com>
Cc: "ardb@kernel.org" <ardb@kernel.org>,
"Lutomirski, Andy" <luto@kernel.org>,
"dvhart@infradead.org" <dvhart@infradead.org>,
"Schofield, Alison" <alison.schofield@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"hughsient@gmail.com" <hughsient@gmail.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"alex@eclypsium.com" <alex@eclypsium.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"daniel.gutson@eclypsium.com" <daniel.gutson@eclypsium.com>,
"andy@infradead.org" <andy@infradead.org>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 0/5] x86: Show in sysfs if a memory node is able to do encryption
Date: Sat, 6 Nov 2021 21:35:16 +0000 [thread overview]
Message-ID: <ec77822e45be2c9736ecb6e101c5321c10b560e7.camel@intel.com> (raw)
In-Reply-To: <20211105212724.2640-1-martin.fernandez@eclypsium.com>
On Fri, 2021-11-05 at 18:27 -0300, Martin Fernandez wrote:
> Show for each node if every memory descriptor in that node has the
> EFI_MEMORY_CPU_CRYPTO attribute.
The problem I have with EFI_MEMORY_CPU_CRYPTO is it that is vague what
memory encryption technology is deployed and does not tell you anything
about whether it is in effect or not.
If this is just for basic inventory for determining if one platform
might be more secure than another then maybe it is ok, but I don't know
how well this will dovetail with CXL that can dynamically define memory
ranges. To date I've only seen a specification for CXL Link encryption,
data at rest encryption for CXL PMEM. I imagine one day it will gain
encryption capabilities, but that won't be something the platform
firmware will always be involved estabishing.
>
> fwupd project plans to use it as part of a check to see if the users
> have properly configured memory hardware encryption capabilities. It's
> planned to make it part of a specification that can be passed to
> people purchasing hardware. It's called Host Security ID:
> https://fwupd.github.io/libfwupdplugin/hsi.html
>
> This also can be useful in the future if NUMA decides to prioritize
> nodes that are able to do encryption.
I'd feel better if this one one step indirected from the raw EFI
attribute and let architectures indicate whether traffic going over the
memory bus (DDR / DDR-T / CXL etc) is known to be encrypted or not.
EFI_MEMORY_CPU_CRYPTO does not communicate that property.
>
> 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 encryption
>
> Documentation/ABI/testing/sysfs-devices-node | 10 ++
> arch/x86/include/asm/e820/api.h | 2 +
> arch/x86/include/asm/e820/types.h | 1 +
> arch/x86/kernel/e820.c | 32 +++++-
> arch/x86/platform/efi/efi.c | 109 +++++++++++++++++++
> drivers/base/node.c | 10 ++
> include/linux/memblock.h | 6 +
> include/linux/mmzone.h | 2 +
> mm/memblock.c | 74 +++++++++++++
> mm/page_alloc.c | 1 +
> 10 files changed, 245 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-devices-node
>
>
> base-commit: 3906fe9bb7f1a2c8667ae54e967dc8690824f4ea
> --
> 2.30.2
>
next prev parent reply other threads:[~2021-11-06 21:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 21:27 [PATCH 0/5] x86: Show in sysfs if a memory node is able to do encryption Martin Fernandez
2021-11-05 21:27 ` [PATCH 1/5] Extend memblock to support memory encryption Martin Fernandez
2021-11-05 23:08 ` Dave Hansen
2021-11-05 21:27 ` [PATCH 2/5] Extend pg_data_t to hold information about " Martin Fernandez
2021-11-05 23:30 ` Dave Hansen
2021-11-05 21:27 ` [PATCH 3/5] Extend e820_table " Martin Fernandez
2021-11-05 23:39 ` Dave Hansen
2021-11-08 18:40 ` Martin Fernandez
2021-11-08 21:13 ` Dave Hansen
2021-11-09 19:16 ` Martin Fernandez
2021-11-05 21:27 ` [PATCH 4/5] Mark e820_entries as crypto capable from EFI memmap Martin Fernandez
2021-11-06 0:02 ` Dave Hansen
2021-11-05 21:27 ` [PATCH 5/5] Show in sysfs if a memory node is able to do encryption Martin Fernandez
2021-11-06 0:04 ` Dave Hansen
2021-11-06 0:49 ` [PATCH 0/5] x86: " Dave Hansen
2021-11-06 21:35 ` Williams, Dan J [this message]
2021-11-07 17:58 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec77822e45be2c9736ecb6e101c5321c10b560e7.camel@intel.com \
--to=dan.j.williams@intel.com \
--cc=alex@eclypsium.com \
--cc=alison.schofield@intel.com \
--cc=andy@infradead.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=daniel.gutson@eclypsium.com \
--cc=dave.hansen@linux.intel.com \
--cc=dvhart@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=hughsient@gmail.com \
--cc=linux-efi@vger.kernel.org \
--cc=luto@kernel.org \
--cc=martin.fernandez@eclypsium.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox