On 10/27/21, Dave Hansen <dave.hansen@xxxxxxxxx> 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.
