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: <20180725171124.kklnori7tf56ngeu@treble>
Date:   Wed, 25 Jul 2018 12:11:24 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     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@...r.kernel.org, x86@...nel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

On Wed, Jul 25, 2018 at 03:50:44PM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Josh Poimboeuf wrote:
> 
> > > The article "Spectre Returns! Speculation Attacks using the Return Stack
> > > Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
> > > making use solely of the RSB contents even on CPUs that don't fallback to
> > > BTB on RSB underflow (Skylake+).
> > > 
> > > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> > > 
> > > [1] https://arxiv.org/pdf/1807.07940.pdf
> > > 
> > > Signed-off-by: Jiri Kosina <jkosina@...e.cz>
> > 
> > While I generally agree with this patch, isn't it odd that we would do
> > RSB filling on every context switch, but almost never do IBPB?
> 
> Yeah, I have actually been wondering exactly the same, but that's what we 
> have been doing so far on SKL+, so I didn't really want to mix this aspect 
> in.
> 
> I actually believe that in the name of consistency we should've been doing 
> the RSB fills under the same conditions we're issuing IBPB even on SKL+; I 
> can resend a patch that re-adjusts that, if that's the consensus.

True, in theory it might make more sense to only fill RSB when doing an
IBPB.  But given the current state of almost never doing IBPB, that
would be pointless.  RSB is cheap enough that we should just do it
unconditionally on context switch.

BTW, I've heard that IBPB actually flushes RSB, though I haven't seen
that officially documented anywhere.  Not that it matters given the
current IBPB code.

BTW^2, there was some discussion a few months back about offloading the
"when to IBPB" decision to security modules, though I don't think I've
ever seen official patches for that.

All that said, this patch is fine until if/when the IBPB strategy gets
figured out.  RSB filling is cheap.

Reviewed-by: Josh Poimboeuf <jpoimboe@...hat.com>

-- 
Josh