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]

Message-Id: <0DD7FAE4-3976-4835-8090-80B84B737F3E@amacapital.net>
Date:   Fri, 19 Jun 2020 08:48:47 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Richard Hughes <hughsient@...il.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        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 Jun 19, 2020, at 6:50 AM, Richard Hughes <hughsient@...il.com> wrote:
> 
> On Fri, 19 Jun 2020 at 14:44, Borislav Petkov <bp@...en8.de> wrote:
>> Yes, this is what I'm proposing with clearing the flag in /proc/cpuinfo.
>> The needed information is there:
>> 1. TME in CPUID
>> 2. TME *not* in /proc/cpuinfo
> 
> No, it's not a boolean at all. If the platform disable is a BIOS
> configuration we don't know if TME isn't available because the CPU
> doesn't support it or because the firmware has disabled it. In the
> latter case, a firmware update or firmware configuration change might
> actually enable it. If the user installs a CPU with TME support and
> then we tell the user "your system doesn't support TME" then we're
> going to have some very confused users unless we can differentiate the
> two cases.
> 
>> Along with proper ABI definition, design,
>> documentation and all that belongs to a proper interface with userspace.
> 
> I don't think Daniels patch was a "final version" and I'm sure
> follow-ups can add this kind of thing. At the moment it's just people
> telling him "you don't need this" when as a potential consumer I'm
> saying we really do.

I think it’s reasonable for the kernel to ask why.

Is the idea that some GUI would show a big warning like “your silly BIOS has TME disabled”?

Boris, it wouldn’t be totally crazy for cpuinfo to learn to distinguish between “your platform has this feature but Linux isn’t using it” and “your platform doesn’t have this feature in the first place”. And I suppose there’s this extra silly state “your platform has this feature, but your firmware didn’t enable it”.  This would be a big job.

Regardless, knowing what the actual point of this patch is would be nice.

> 
> Richard.