linux-kernel - Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch

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: <3aadb8a0-08c8-bdf9-7b91-0fa774a9e1ab@citrix.com>
Date:   Tue, 9 Jan 2018 01:15:57 +0000
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andi Kleen <ak@...ux.intel.com>
Cc:     "Woodhouse, David" <dwmw@...zon.co.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "riel@...hat.com" <riel@...hat.com>,
        "keescook@...gle.com" <keescook@...gle.com>,
        "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "pjt@...gle.com" <pjt@...gle.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "luto@...capital.net" <luto@...capital.net>,
        "jikos@...nel.org" <jikos@...nel.org>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>
Subject: Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on
 context switch

On 09/01/2018 00:58, Linus Torvalds wrote:
> On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen <ak@...ux.intel.com> wrote:
>> Essentially the RSB are hidden registers, and the only way to clear them
>> is the FILL_RETURN_BUFFER sequence.  I don't see how clearing anything else
>> would help?
> Forget theory. Look at practice.
>
> Let's just assume that the attacker can write arbitrarily to the RSB
> state.  Just accept it.
>
> If you accept that, then you turn the question instead into: are there
> things we can do to make that useless to an attacker.
>
> And there the point is that even if you control the RSB contents, you
> need to find something relevant to *put* in the RSB. You need to find
> the gadget that makes that control of the RSB useful.

This is where the problem lies.  An attacker with arbitrary control of
the RSB can redirect speculation arbitrarily.  (And I agree, this is a
good default assumption to take).

If SMEP is not active, speculation can go anywhere, including to a user
controlled gadget which can reload any registers it needs, including
with immediate constants.

If SMEP is active, the attackers control of speculation is restricted to
supervisor executable mappings.

The real question is whether it is worth special casing the SMEP-active
case given that for the SMEP-inactive case, your only viable option is
to refill the RSB and discard any potentially poisoned mappings.

~Andrew