Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs

From: Martin Fernandez <martin.fernandez@eclypsium.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com,
	luto@kernel.org, peterz@infradead.org, ardb@kernel.org,
	dvhart@infradead.org, andy@infradead.org,
	gregkh@linuxfoundation.org, rafael@kernel.org,
	daniel.gutson@eclypsium.com, hughsient@gmail.com
Subject: Re: [PATCH v2 0/5] [RFC] x86: Export information about hardware memory encryption to sysfs
Date: Thu, 28 Oct 2021 11:28:57 -0300	[thread overview]
Message-ID: <CAKgze5Z3fT9F0S-mogfP6is9sL3=0imtCbfy6ZYrd3zgaBUqRg@mail.gmail.com> (raw)
In-Reply-To: <8a8e0743-e54d-ec96-da4e-1d101b550274@intel.com>

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