linux-kernel - Re: Avoid speculative indirect calls in kernel

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: <20180104165238.GF13348@redhat.com>
Date:   Thu, 4 Jan 2018 17:52:38 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     "Woodhouse, David" <dwmw@...zon.co.uk>
Cc:     "pavel@....cz" <pavel@....cz>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "andi@...stfloor.org" <andi@...stfloor.org>,
        "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>
Subject: Re: Avoid speculative indirect calls in kernel

On Thu, Jan 04, 2018 at 03:29:37PM +0000, Woodhouse, David wrote:
> On Thu, 2018-01-04 at 14:51 +0000, Andrew Cooper wrote:
> > 
> > > * never turn off indirect branch prediction, but use a branch prediction
> > > barrier on every mode switch (needed for current AMD microcode)
> > 
> > Where have you got this idea from?  Using IBPB on every mode switch
> > would be an insane overhead to take, and isn't necessary.
> 
> AMD *only* has IBPB and not IBRS, but IIRC you don't need to do it on

AMD 0x10 0x12 0x16 basically have IBRS and no IBPB, those works
perfectly fine in ibrs 2 ibpb 1 mode, variant#2 fixed and zero
overhead.

> every context switch into the kernel; only when switching between
> VMs/processes?

Some AMD only has IBPB and no IBRS, then IBPB has to be called in
every enter kernel or vmexit to give the same security as ibrs 1 ibpb
1 (modulo SMT/HT but that's not the spectre PoC and you can rule that
out mathematically also by simply using cpu pinning as you already do
or disabling SMT if you care that much). Note ibrs 1 ibpb 1 also won't
cover HT effects of guest/user mode vs guest/user mode so cpu pinning
may be advisable anyway in your case (even with ibrs 1 ibpb 1 no
difference).

Of course everything can be trivially opted out at runtime and all
measurable performance restored, but by default it boots in the most
secure config available and it will make spectre variant#2 attack
impossible with only ibpb available.

> I need to pull in the AMD lfence alternative for retpoline, giving us a
> 3-way choice of the existing retpoline thunk, "lfence; jmp *%\reg", and
> a bare "jmp *%\reg".
> 
> Then the IBRS bits can be added on top.

"AMD lfence and reptoline" in the same sentence sounds like somebody
else also cares about spectre variant#2 on AMD. "Reptoline" only ever
makes sense in spectre variant#2 context so either ibrs 0 ibpb 2 mode
makes some sense too, or special lfence repotline for AMD should not
be worth mentioning in the first place.