linux-kernel - Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

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: <20180110120721.GC9706@redhat.com>
Date:   Wed, 10 Jan 2018 13:07:21 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>, x86@...nel.org,
        Borislav Petkov <bp@...en8.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control
 code

On Wed, Jan 10, 2018 at 01:01:58PM +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 11:58:54AM +0000, David Woodhouse wrote:
> > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote:
> > > On Wed, Jan 10, 2018 at 09:27:59AM +0000, David Woodhouse wrote:
> > > > I don't know why you're calling that 'IBRS=2'; are you getting
> > > confused
> > > > by Andrea's distro horridness?
> > > 
> > > Eh, yes he's got confused. ibrs_enabled 2 simply means to leave IBRS
> > > set in SPEC_CTLR 100% of the time, except in guest mode.
> > 
> > On all current hardware, if you only set IBRS when you exit a guest,
> > then you are not protecting yourself from userspace at all. IBRS acts
> > as a *barrier* in all current hardware.
> 
> Kernel memory is 100% protected if you set only IBRS at vmexit.
> 
> Once IBRS is set, there's no way any userland (nor host nor guest) can
> attack the kernel memory through spectre variant#2.
> 
> What is not protected is host userland from guest userland which is
> point 3 in the email I posted earlier and I already provided all
> details there on how to fix that purely theoretical issue not part of
> the PoC with the provided debugfs tunables, so I won't repeat here.

Also I read in another email you thought IBRS is a barrier or
something, it's not, it's purely temporarily preventing the CPU to
speculate through IBP BTB whatever, it will do the least possible
amount of work without altering the internal state that can still be
poisoned by the attacker but it's no problem because kernel mode won't
make any use of that "poison". IBRS won't flush anything, the poison
stays there, it's not barrier, and IBPB is the only barrier that
flushes the content.

IBPB is expensive but after IBPB you return running at core full speed
but you can't be influenced by any poison somebody put in the CPU to
influence your runtime. IBRS as opposed is not expensive to execute
(relatively speaking) but then the CPU runs slower as it can't use
those parts of the CPU that may have been poisoned by the attacker.

So you can also flush the whole content of IBP/BTB at vmexit with IBPB
instead of setting SPECT_CTRL to IBRS. Same thing at kernel entry. If
you do that and you don't care about SMT/HT effect it's equivalent to
setting IBRS at vmexit/kernelentry and in fact it'll also protect host
userland from guest userland.

Hope this clarifies what those IBRS IBPB features achieve.

Thanks,
Andrea