[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD2FfiGxy=9ARK5FT_iaLACZSzR+R4crmGJv7T+v_w3+ktOzCQ@mail.gmail.com>
Date: Wed, 15 Jun 2022 20:34:58 +0100
From: Richard Hughes <hughsient@...il.com>
To: Alison Schofield <alison.schofield@...el.com>
Cc: Martin Fernandez <martin.fernandez@...ypsium.com>,
linux-kernel@...r.kernel.org, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, mingo@...hat.com,
tglx@...utronix.de, daniel.gutson@...ypsium.com,
alex.bazhaniuk@...ypsium.com
Subject: Re: [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is
disabled by BIOS
On Wed, 15 Jun 2022 at 20:06, Alison Schofield
<alison.schofield@...el.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.
> 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.
Powered by blists - more mailing lists