linux-kernel - Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

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:   Mon, 29 Jan 2018 15:07:37 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Jon Masters <jcm@...masters.org>
Cc:     KarimAllah Ahmed <karahmed@...zon.de>,
        linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Borislav Petkov <bp@...e.de>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        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>,
        Jun Nakajima <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>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>, kvm@...r.kernel.org,
        x86@...nel.org
Subject: Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching
 into non dumpable process

On Mon, Jan 29, 2018 at 01:35:30AM -0500, Jon Masters wrote:
> > So if I understand it right, this is only needed if the 'other'
> > executable itself is susceptible to spectre. If say someone audited gpg
> > for spectre-v1 and build it with retpoline, it would be safe to not
> > issue the IBPB, right?
> 
> More importantly, rebuilding the world introduces a lot of challenges
> that need to be discussed heavily before they happen (I would like to
> see someone run a session at one of the various upcoming events on
> userspace, I've already prodded a few people to nudge that forward). In
> particular, we don't have the infrastructure in gcc/glibc to dynamically
> patch userspace call sites to enable/disable retpolines.

GCC/GLIBC do in fact have some infrastructure for this; see
target_clones/ifunc function attributes. We can at (dynamic) link time
select between alternative functions.

With this we could select different retpoline thunks for different
systems, much like what we end up doing for the kernel.

> We discussed nasty hacks last year (I even suggested an ugly kernel
> exported page similar to VDSO that could be implementation patched for
> different uarches), but the bottom line is there isn't anything in place
> to provide a similar userspace experience to what the kernel can do, and
> that would need to be solved in addition to the ELF/ABI bits.

Not sure where you discussed what, but I spoke with a bunch of the
facebook people at plumbers about kernel support for (runtime) userspace
patching a-la asm-goto/jump-labels.

And while that would be entirely fun, I don't see how we'd need this
here.

> > So would it make sense to provide an ELF flag / personality thing such
> > that userspace can indicate its spectre-safe?
> > 
> > I realize that this is all future work, because so far auditing for v1
> > is a lot of pain (we need better tools), but would it be something that
> > makes sense in the longer term?
> 
> So I would just caution that doing this isn't necessarily bad, but it's
> far more than just ELF bits and rebuilding. Once userspace is rebuilt
> with un-nopable retpolines, they're there whether you need them on
> $future_hardware or not, and that fancy branch predictor is useless. So
> we really need a way to allow for userspace patchable calls, or at least
> some kind of plan before everyone runs away with rebuilding.

Just rebuild world again; there's plenty distros where this is not in
fact a difficult thing to do :-) You just don't happen to work for one
... :-)