[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67d2711b-200c-0894-4ff7-beb3eb304399@amd.com>
Date: Thu, 3 Feb 2022 21:47:02 -0600
From: "Limonciello, Mario" <mario.limonciello@....com>
To: Martin Fernandez <martin.fernandez@...ypsium.com>,
linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
platform-driver-x86@...r.kernel.org, linux-mm@...ck.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
ardb@...nel.org, dvhart@...radead.org, andy@...radead.org,
gregkh@...uxfoundation.org, rafael@...nel.org, rppt@...nel.org,
akpm@...ux-foundation.org, daniel.gutson@...ypsium.com,
hughsient@...il.com, alex.bazhaniuk@...ypsium.com,
alison.schofield@...el.com, keescook@...omium.org,
"Lendacky, Thomas" <Thomas.Lendacky@....com>
Subject: Re: [PATCH v6 6/6] drivers/node: Show in sysfs node's crypto
capabilities
On 2/3/2022 10:43, Martin Fernandez wrote:
> Show in each node in sysfs if its memory is able to do be encrypted by
> the CPU, ie. if all its memory is marked with EFI_MEMORY_CPU_CRYPTO in
> the EFI memory map.
>
> Signed-off-by: Martin Fernandez <martin.fernandez@...ypsium.com>
> ---
> Documentation/ABI/testing/sysfs-devices-node | 10 ++++++++++
> drivers/base/node.c | 10 ++++++++++
> 2 files changed, 20 insertions(+)
> 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..0d1fd86c9faf
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-node
> @@ -0,0 +1,10 @@
> +What: /sys/devices/system/node/nodeX/crypto_capable
> +Date: February 2022
> +Contact: Martin Fernandez <martin.fernandez@...ypsium.com>
> +Users: fwupd (https://fwupd.org)
> +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.
> \ No newline at end of file
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 87acc47e8951..dabaed997ecd 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -560,11 +560,21 @@ 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);
As there is interest in seeing these capabilities from userspace, it
seems like a logical time to also expose a `crypto_active` attribute.
Then userspace can make a judgement call if the system supports crypto
memory (`crypto_capable`) and then also whether or not it's been turned
on (`crypto_active`).
`crypto_active` could be detected with some existing support in the
kernel of `mem_encrypt_active()`. This will then work for a variety of
architectures too that offer `mem_encrypt_active()`.
As it stands today the only reliable way to tell from userspace (at
least for AMD's x86 implementation) is by grepping the system log for
the line "AMD Memory Encryption Features active".
> +}
> +static DEVICE_ATTR_RO(crypto_capable);
> +
> 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
> };
>
Powered by blists - more mailing lists