linux-kernel - Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

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: <20180725232754.libahpxmohmv3vtp@treble>
Date:   Wed, 25 Jul 2018 18:27:55 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Borislav Petkov <bp@...e.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Peter Zijlstra <peterz@...radead.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

On Thu, Jul 26, 2018 at 01:11:01AM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Linus Torvalds wrote:
> 
> > > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> > 
> > Shouldn't this also do something like
> > 
> >      x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP;
> > 
> > if we have HT enabled?
> 
> So IIUC your comment is not really tightly related to spectreRSB, is it?
> 
> If you're making a more general remark about things that we'd also have to 
> do in order to improve userspace-userspace spectrev2 prevention, then I 
> agree.
> 
> It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I 
> think though, as the VM switching also has to save/restore it properly 
> (the same way we handle SSBD). So I'd rather handle this separately, as it 
> really is in principle a completely different protection.
> 
> STIBP is plugging much smaller hole than spectreRSB (as the bigger part is 
> already plugged by IBPB)

Just to clarify, the IBPB hole is *not* plugged for context switches.
It's only enabled for non-dumpable processes (which are basically
non-existent in practice).

> so I'd rather have that one in first, and look at improving STIBP
> later if noone beats me to it.

It would be interesting to see performance measurements for STIBP, but
based on what we've seen with IBRS in user space, I'd guess that it's
not pretty.

-- 
Josh