MIME-Version: 1.0
In-Reply-To: <nycvar.YFH.7.76.1801081137530.11852@cbobk.fhfr.pm>
References: <1515363085-4219-1-git-send-email-dwmw@amazon.co.uk>
 <CAPM31R+ErDgVf4=U6v21bhN9a9MEN-S6U95FmHbGGw7NP+e5ZA@mail.gmail.com> <nycvar.YFH.7.76.1801081137530.11852@cbobk.fhfr.pm>
From: Paul Turner <pjt@google.com>
Date: Mon, 8 Jan 2018 02:45:40 -0800
Message-ID: <CAPM31RKg_H96eekKhf3U8CjABpe5VimQx3Ya9t8gZR0mXM_X4w@mail.gmail.com>
Subject: Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel
To: Jiri Kosina <jikos@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>,
        Andi Kleen <ak@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linux-foundation.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Kees Cook <keescook@google.com>,
        Rik van Riel <riel@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@amacapital.net>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org

On Mon, Jan 8, 2018 at 2:38 AM, Jiri Kosina <jikos@kernel.org> wrote:
> 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.
>

See 2.6.1.1 [Replicated resources]:
  "The return stack predictor is replicated to improve branch
prediction of return instructions"

(This is part of the reason that the sequence is attractive; its use
of the RSB to control prediction naturally prevents cross-sibling
attack.)

> --
> Jiri Kosina
> SUSE Labs
>