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: <CALCETrVieskMnU5XHKHYm+qOfzc+o4yhsGw42pvBNhkv2zsQJA@mail.gmail.com>
Date:   Fri, 19 Jun 2020 13:20:48 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Richard Hughes <hughsient@...il.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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 ML <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
        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, Jun 19, 2020 at 12:58 PM Richard Hughes <hughsient@...il.com> wrote:
>
> On Fri, 19 Jun 2020 at 20:41, Andy Lutomirski <luto@...nel.org> wrote:
> > I don't object in principle to Linux giving userspace more visibility
> > into what's going on, but I'm not convinced that adding a new
> > must-support-for-a-long-time interface that only solves 5% of your
> > problem is worth it.
>
> At the moment the only visibility we have is "the CPU supports TME"
> and "the kernel printed a message in the journal". The sysfs/procfs
> file read allows us to notify the admin if the firmware is
> deliberately disabling TME for some reason, without resorting to
> `grep` on dmesg. I don't think perfect should be the enemy of the
> good.

I am unconvinced that this has hit the "good" bar, especially since
SME is completely missing here.

Boris, etc: would it be reasonable to add a list of CPU features that
are present but turned off by firmware?  SME is far from the only
thing that's frequently in this category.  x2apic, fast strings, and
virtualization come to mind.

>
> Richard.