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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 21 Jan 2018 20:04:07 +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 19:37 +0000, Andrew Cooper wrote:
> 
> It doesn't matter if an attacker can use SP1 to try and skip the IBPB.
> 
> Exits to userspace/guest are serialising (with some retroactive updates
> to the architecture spec coming), so an attacker can't cause victim code
> to be executed before speculation has caught up and noticed that the
> IBPB did need to happen.

For the specific case of IBPB, knowing what we do about non-
architectural behaviour, that's probably true.

In the early patch sets in both Xen and Linux, we did have a
conditional branch on {sys,hyper}call entry that blithely let the CPU
speculate all the way to the {sys,hyper}call table jump. No exit to
userspace/guest there.

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.

ALTERNATIVE is fine for now, and can end up with basically the same
code as static_cpu_has() — either we do the wrmsr, or we jump/nop over
where it used to be. Let's worry about getting clever with it *later*.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)