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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ