linux-kernel - Re: [PATCH] Ability to read the MKTME status from userspace

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:   Fri, 19 Jun 2020 14:31:11 +0100
From:   Richard Hughes <hughsient@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Daniel Gutson <daniel@...ypsium.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh@...nel.org>, Tony Luck <tony.luck@...el.com>,
        Rahul Tanwar <rahul.tanwar@...ux.intel.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Ability to read the MKTME status from userspace

On Fri, 19 Jun 2020 at 14:22, Borislav Petkov <bp@...en8.de> wrote:
> And how is the user going to know from your "module"? AFAICT, your
> module loads on any system - not only on ones which have MKTME in CPUID.

I maintain fwupd, which would be one consumer of this information. At
the moment we already look at the CPUID for the TME flag, which
successfully recognises CPU systems which support the feature. What we
don't know is if the firmware platform has disabled the MKTME feature.
Ideally we would export two things:

1. that the CPU supports TME (->cpuid, already done)
2. that the platform has not disabled TME in some way

The only way we have at the moment to see if TME is supported on the
platform (rather than just the CPU) is by grepping the entire systemd
journal at boot time, grepping for the "x86/tme: enabled by BIOS"
string. With a securityfs/sysfs/procfs file we don't have to do this
expensive operation for reading one tiny bit of data.

Richard