From: Alison Schofield <alison.schofield@intel.com>
To: Richard Hughes <hughsient@gmail.com>
Cc: Martin Fernandez <martin.fernandez@eclypsium.com>,
linux-kernel@vger.kernel.org, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, mingo@redhat.com,
tglx@linutronix.de, daniel.gutson@eclypsium.com,
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 12:54:25 -0700 [thread overview]
Message-ID: <20220615195425.GA1524649@alison-desk> (raw)
In-Reply-To: <CAD2FfiGxy=9ARK5FT_iaLACZSzR+R4crmGJv7T+v_w3+ktOzCQ@mail.gmail.com>
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? 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.
next prev parent reply other threads:[~2022-06-15 19:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 21:02 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 [this message]
2022-06-15 20:26 ` Daniel Gutson
2022-06-15 20:48 ` Martin Fernandez
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=20220615195425.GA1524649@alison-desk \
--to=alison.schofield@intel.com \
--cc=alex.bazhaniuk@eclypsium.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=martin.fernandez@eclypsium.com \
--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
all inboxes | Powered by JetHome®