linux-kernel - Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

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:   Sun, 21 Jan 2018 21:25:10 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Andrew Cooper <andrew.cooper3@...rix.com>,
        Borislav Petkov <bp@...en8.de>,
        KarimAllah Ahmed <karahmed@...zon.com>
Cc:     arjan@...ux.intel.com, tglx@...utronix.de, karahmed@...zon.de,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        tim.c.chen@...ux.intel.com, peterz@...radead.org,
        pbonzini@...hat.com, ak@...ux.intel.com,
        torvalds@...ux-foundation.org, gregkh@...ux-foundation.org
Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, 2018-01-21 at 20:19 +0000, Andrew Cooper wrote:
> On 21/01/2018 20:04, David Woodhouse wrote:
> > For the specific case of IBPB, knowing what we do about non-
> > architectural behaviour, that's probably true.
> 
> This IBPB case is an attacker trying to attack a new piece of userspace
> using SP2, and furthermore, trying to use SP1 to skip the IBPB.
> ...
> As the exit to user/guest context is serialising, the only thing the
> attacker can usefully do is tickle a speculatively-leaky block.

Right, I think we're saying the same things above. It's probably OK for
IBPB given that we know that vmlaunch is *really* serialising despite
not being architecturally so.

And sure, all of these attacks are *highly* improbable. The one on the
way into the syscall was the really easy one.

> > Which is why I've been saying I want call sites to have an *explicit*
> > comment saying why they're safe to use conditional branches without
> > taking extra steps to be safe, like the 'else lfence'. And why I'd
> > really like the underlying primitives to *support* being fixed at
> > runtime.
> 
> I'm afraid that, by this logic, every conditional branch needs a
> comment, and that is impractical.  I don't see what is special about
> this conditional branch vs every other conditional branch in the
> codebase, and calling it out in isolation feels wrong.

The code paths these are going into are general fairly linear, and
they're inserted at the point where they can't be bypassed by any
condition *except* the corresponding boot_cpu_has(IBxx). Are there
other conditional branches that would take us right across the wrmsr
and into vulnerable code? 

Maybe I am being overly paranoid and it really was just that *one* IBRS
write in the syscall path that was vulnerable, and all the rest would
be fine. I'd still rather start simple and use alternatives for now,
and then get clever later. It's not like there's a real *problem* with
using alternatives.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)