lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Jun 2022 17:26:23 -0300
From:   Daniel Gutson <daniel.gutson@...ypsium.com>
To:     Alison Schofield <alison.schofield@...el.com>
Cc:     Richard Hughes <hughsient@...il.com>,
        Martin Fernandez <martin.fernandez@...ypsium.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alex Bazhaniuk <alex.bazhaniuk@...ypsium.com>
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@...el.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@...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.
> >
> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ