linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Fernandez <martin.fernandez@eclypsium.com>
To: Daniel Gutson <daniel.gutson@eclypsium.com>
Cc: Alison Schofield <alison.schofield@intel.com>,
	Richard Hughes <hughsient@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alex Bazhaniuk <alex.bazhaniuk@eclypsium.com>
Subject: Re: [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS
Date: Wed, 15 Jun 2022 17:48:34 -0300	[thread overview]
Message-ID: <CAKgze5aQsh2VY4tjsDco_Wc6CTU+KXZM3bhFR+73AVp3gLWHuA@mail.gmail.com> (raw)
In-Reply-To: <CAFmMkTGFpehSFOsnDuQN4aTnwfgYGwTbGBxtvUU_byDcoRVPPA@mail.gmail.com>

On 6/15/22, Daniel Gutson <daniel.gutson@eclypsium.com> wrote:
> On Wed, Jun 15, 2022 at 4:54 PM Alison Schofield
> <alison.schofield@intel.com> 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@intel.com> 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@eclypsium.com/

[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.
>

  reply	other threads:[~2022-06-15 20:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14 21:02 [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS Martin Fernandez
2022-06-14 21:05 ` Richard Hughes
2022-06-15 19:05 ` Alison Schofield
2022-06-15 19:34   ` Richard Hughes
2022-06-15 19:54     ` Alison Schofield
2022-06-15 20:26       ` Daniel Gutson
2022-06-15 20:48         ` Martin Fernandez [this message]
2022-06-15 20:59           ` Alison Schofield
2022-06-16  2:10 ` Kai Huang
2022-06-16 14:23   ` Martin Fernandez
2022-07-04 14:20 Martin Fernandez
2022-07-04 14:22 ` Martin Fernandez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKgze5aQsh2VY4tjsDco_Wc6CTU+KXZM3bhFR+73AVp3gLWHuA@mail.gmail.com \
    --to=martin.fernandez@eclypsium.com \
    --cc=alex.bazhaniuk@eclypsium.com \
    --cc=alison.schofield@intel.com \
    --cc=bp@alien8.de \
    --cc=daniel.gutson@eclypsium.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hughsient@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).