On 2/4/2022 11:12, Tom Lendacky wrote:
On 2/4/22 10:28, Borislav Petkov wrote:
On Fri, Feb 04, 2022 at 10:23:22AM -0600, Limonciello, Mario wrote:
As there is interest in seeing these capabilities from userspace, it
This needs to be explained in a lot more detail: why, what is going to
use it, how, etc.
We don't do user-visible APIs just because.
The fwupd daemon has a feature that measures various security aspects of
the system hardware, software and firmware and reflects it out to
consumers (fwupd clients) in an easily consumable format, in some cases
with actionable notes.
In this case the information would be used to make a check about memory
encryption support and enablement. If a sysfs file was made then it
could be something like this:
1) fwupd checks /sys/security/memory_encryption
1: You're encrypted, here's a gold star.
0: keep checking
2) fwupd checks does /proc/cpuinfo have sme, sev_es, or mktme?
No: Your hardware doesn't support encryption, tell the user.
Yes: keep going.
3)AMD?
Check /proc/cmdline, Did user set mem_encrypt=off on explicitly?
That's why. Tell user they can enable it with mem_encrypt=on or
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
mem_encrypt=on/CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT?
We've got a kernel or hardware problem.
4) Intel?
Document Intel's path to turn it on.
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 we should clear that "sme" flag if memory encryption is not
enabled. Like we do for all other flags.
If we do that, then this will have to be re-worked:
https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/process.c#L761
I guess if sme/sev/sev_es "are" torn out of cpuinfo when encryption is
turned off then that "could" instead do the MSR read perhaps?
Thanks,
Tom
