Re: [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS

[Martin Fernandez]

On 6/15/22, Daniel Gutson <daniel.gutson@xxxxxxxxxxxxx> wrote:
> On Wed, Jun 15, 2022 at 4:54 PM Alison Schofield
> <alison.schofield@xxxxxxxxx> wrote:
>>
>> On Wed, Jun 15, 2022 at 08:34:58PM +0100, Richard Hughes wrote:
>> > On Wed, 15 Jun 2022 at 20:06, Alison Schofield
>> > <alison.schofield@xxxxxxxxx> wrote:
>> > > My first reaction is lying about the cpuinfo is not a soln, since
>> > > it creates a problem for a users currently relying on cpuinfo to be
>> > > the source of truth for TME.
>> >
>> > I think you have to qualify "source of truth". At the moment the CPU
>> > reports "Yes! I support TME!" and then for one reason or another the
>> > platform turns it off and actually there's no memory encryption of
>> > your secrets at all. There's seemingly no userspace way of telling if
>> > TME is actually active. We were told that we shouldn't export the
>> > "platform has disabled a CPU feature" in sysfs and just to clear the
>> > cpuid flag that gets exported (like AMD is currently doing) which is
>> > what Martin proposed here. Programs want to know the true CPU
>> > capability can do __get_cpuid_count() like they can for the SME/SEV
>> > capabilities.
>> >
>> Disagree on sending folks to use __get_cpuid_count() when they already
>> have cpuinfo.
>>
>> Why is a sysfs entry TME-enabled 0/1 a bad thing?
>
> :)))
> This was my very first patch, and I got half of the community complaining
> It was so long ago that I don't recall everything, maybe Martín does?
> or Richard?

The discussion triggered the fact that checking that TME is active is
not enough to tell if memory is being encrypted or not (which we
thought it was true by that time), and that triggered a series of patches to
address the other checks required, which is currently going nowhere
[1].

The sysfs _wasn't_ discarded perse, but since Boris suggested the
change in cpuinfo (several times now that I recalled that Daniel patch
[2]) I think that is cleaner, besides the backwards compatibility.

[1] https://lore.kernel.org/linux-efi/20220429201717.1946178-1-martin.fernandez@xxxxxxxxxxxxx/

[2] https://lkml.iu.edu/hypermail/linux/kernel/2006.2/05231.html

>> It can be documented
>> to have the same meaning as the log message.
>>
>> You keep referring to AMD. How is their exception documented?
>>
>> Alison
>>
>> > > Are we to tell them to go look in the
>> > > log now, because fwupd folks didn't want to ;)
>> >
>> > We're not telling anyone to use the log; grepping megabytes of
>> > unformatted kernel logs is a terrible (and slow) way to get one
>> > boolean value.
>> >
>> > Richard.
>