Messages in this thread | | | From | Daniel Gutson <> | Date | Wed, 15 Jun 2022 17:26:23 -0300 | Subject | Re: [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS |
| |
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?
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.
| |