linux-kernel - Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

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, 16 Feb 2018 11:38:19 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        Rik van Riel <riel@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Kosina <jikos@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Kees Cook <keescook@...gle.com>,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Paul Turner <pjt@...gle.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>
Subject: Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

On Fri, Feb 16, 2018 at 11:17 AM, Dave Hansen
<dave.hansen@...ux.intel.com> wrote:
>
> Intel is considering adding a new bit to the IA32_ARCH_CAPABILITIES
> MSR to tell when RSB underflow might be happen.  Feedback on this
> would be greatly appreciated before the specification is finalized.

Yes, please. It would be lovely to not have any "this model" kind of checks.

Of course, your patch still doesn't allow for "we claim to be skylake
for various other independent reasons, but the RSB issue is fixed".

So it might actually be even better with _two_ bits: "explicitly needs
RSB stuffing" and "explicitly fixed and does _not_ need RSB stuffing".

And then if neither bit it set, we fall back to the implicit "we know
Skylake needs it".

If both bits are set, we just go with a "CPU is batshit schitzo"
message, and assume it needs RSB stuffing just because it's obviously
broken.

             Linus