On 2/4/2022 09:59, Tom Lendacky wrote:
On 2/4/22 07:21, Martin Fernandez wrote:
On 2/4/22, Limonciello, Mario <mario.limonciello@xxxxxxx> wrote:
On 2/3/2022 10:43, Martin Fernandez wrote:
+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.
I planned to do something similar to this, but to show (or actually
hide if inactive) tme in cpuinfo, just as Borislav Petkov suggested a
few versions back.
https://lore.kernel.org/linux-efi/YXrnkxgdjWbcPlJA@xxxxxxx/
As Tom agreed in previous post, Boris is mistaken here. I just double
checked on my side on a workstation that supports SME and comparing
/proc/cpuinfo before and after SME is enabled via mem_encrypt=on. I
confirmed that nothing changed.
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()`.
I need a hand with this, I grepped for mem_encrypt_active and nothing
showed up...
The mem_encrypt_active() function has been replaced by
cc_platform_has(CC_ATTR_MEM_ENCRYPT).
Yes, thanks for correcting it .
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".
Isn't enough to grep for sme/sev in cpuinfo?
No, it's not enough. Cpuinfo shows a processors capabilities and not
necessarily whether that capability is being used.
Thanks,
Tom
Tom,
Maybe some sysfs file(s) directly from cc_platform.c makes more sense then?
