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-next>] [day] [month] [year] [list]

Message-ID: <nycvar.YFH.7.76.1801081137530.11852@cbobk.fhfr.pm>
Date:   Mon, 8 Jan 2018 11:38:56 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Paul Turner <pjt@...gle.com>
cc:     David Woodhouse <dwmw@...zon.co.uk>,
        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>,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in
 kernel

On Mon, 8 Jan 2018, Paul Turner wrote:

> user->kernel in the absence of SMEP:
> In the absence of SMEP, we must worry about user-generated RSB entries
> being consumable by kernel execution.
> Generally speaking, for synchronous execution this will not occur (e.g.
> syscall, interrupt), however, one important case remains.
> When we context switch between two threads, we should flush the RSB so that
> execution generated from the unbalanced return path on the thread that we
> just scheduled into, cannot consume RSB entries potentially installed by
> the prior thread.

I am still unclear whether this closes it completely, as when HT is on, 
the RSB is shared between the threads, right? Therefore one thread can 
poision it for the other without even context switch happening.

-- 
Jiri Kosina
SUSE Labs