linux-kernel - RE: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

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: <0575AF4FD06DD142AD198903C74E1CC87A5F0AC5@ORSMSX103.amr.corp.intel.com>
Date:   Wed, 24 Jan 2018 01:59:47 +0000
From:   "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>
CC:     "Woodhouse, David" <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        KarimAllah Ahmed <karahmed@...zon.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>,
        Borislav Petkov <bp@...e.de>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Janakarajan Natarajan <Janakarajan.Natarajan@....com>,
        Joerg Roedel <joro@...tes.org>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        Laura Abbott <labbott@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Radim Krcmár <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        kvm list <kvm@...r.kernel.org>, X86 ML <x86@...nel.org>
Subject: RE: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
 Indirect Branch Speculation

> > It is a reasonable approach.  Let a process who needs max security
> > opt in with disabled dumpable. It can have a flush with IBPB clear before
> > starting to run, and have STIBP set while running.
> >
> 
> Do we maybe want a separate opt in?  I can easily imagine things like
> web browsers that *don't* want to be non-dumpable but do want this
> opt-in.

eventually we need something better. Probably in addition.
dumpable is used today for things that want this.

> 
> Also, what's the performance hit of STIBP?

pretty steep, but it depends on the CPU generation, for some it's cheaper than others. (yes I realize this is a vague answer, but the range is really from just about zero to oh my god)

I'm not a fan of doing this right now to be honest. We really need to not piece meal some of this, and come up with a better concept of protection on a higher level.
For example, you mention web browsers, but the threat model for browsers is generally internet content. For V2 to work you need to get some "evil pointer" into the app from the observer and browsers usually aren't doing that.
The most likely user would be some software-TPM-like service that has magic keys.

And for keys we want something else... we want an madvice() sort of thing that does a few things, like equivalent of mlock (so the key does not end up in swap), not having the page (but potentially the rest) end up in core dumps, and the kernel making sure that if the program exits (say for segv) that the key page gets zeroed before going into the free pool. Once you do that as feature, making the key speculation safe is not too hard (intel and arm have cpu options to mark pages for that)