linux-kernel - Re: [PATCH v6 00/10] Retpoline: 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]

Date:   Wed, 10 Jan 2018 15:20:45 +0000
From:   "Woodhouse, David" <dwmw@...zon.co.uk>
To:     Paul Turner <pjt@...gle.com>,
        Tom Lendacky <thomas.lendacky@....com>
CC:     Andi Kleen <ak@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        "Dave Hansen" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Kees Cook" <keescook@...gle.com>, Rik van Riel <riel@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...capital.net>,
        Jiri Kosina <jikos@...nel.org>,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls
 in kernel

On Mon, 2018-01-08 at 02:42 -0800, Paul Turner wrote:
> 
> While the cases above involve the crafting and use of poisoned
> entries.  Recall also that one of the initial conditions was that we
> should avoid RSB underflow as some CPUs may try to use other indirect
> predictors when this occurs.

I think we should start by deliberately ignoring the CPUs which use the
other indirect predictors on RSB underflow. Those CPUs don't perform
*quite* so badly with IBRS anyway.

Let's get the minimum amount of RSB handling in to cope with the pre-
SKL CPUs, and then see if we really do want to extend it to make SKL
100% secure in retpoline mode or not.

So let's go through your list of cases and attempt to distinguish the
underflow concerns (which I declare we don't care about for now) from
the pollution (which we care about especially for non-SMEP) concerns...

> The cases we care about here are:
> - When we return _into_ protected execution.  For the kernel, this
> means when we exit interrupt context into kernel context, since may
> have emptied or reduced the number of RSB entries while in iinterrupt
> context.

Don't care about that particular example. That's underflow-only.

However, we *do* care about entry to kernel code from userspace, for
interrupts and system calls etc. Basically everywhere that the IBRS
code would be setting IBRS, we need to flush the RSB (if !SMEP, I
think).

> - Context switch (even if we are returning to user code, we need to
> at unwind the scheduler/triggering frames that preempted it
> previously, considering that detail, this is a subset of the above,
> but listed for completeness)

Don't care. This is underflow-only. (Which means I think we want to
drop Andi's patch?)

> - On VMEXIT (it turns out we need to worry about both poisoned
> entries, and no entries, the solution is a single refill
> nonetheless).

Do care. This fixes pollution from the guest, and even SMEP isn't
enough to make us not care.

> - Leaving deeper (>C1) c-states, which may have flushed hardware
> state

Don't care.

> - Where we are unwinding call-chains of >16 entries[*]

Don't care.

Overall, I think the RSB-stuffing is needed in all the same places that
it's needed with IBRS.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5210 bytes)