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]

Date:   Tue, 9 Jan 2018 10:09:16 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "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>,
        "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 Tue, Jan 9, 2018 at 5:04 AM, David Woodhouse <dwmw2@...radead.org> wrote:
> On Mon, 2018-01-08 at 19:27 -0800, Andy Lutomirski wrote:
>>
>> I thought that, even on pre-SMEP hardware, the CPU wouldn't
>> speculatively execute from NX pages.  And PTI marks user memory NX
>> in kernel mode.
>
> Hm, now that could be useful.
>
> Do *all* the KPTI backports (some of which are reimplementations rather
> than strictly backports) mark user memory NX?

As Kees said - yes. We're looking at patches to mark some processes
trusted and turn off KPTI for those, and then they'll obviously not
have that, but the whole point is that you'd trust them.

Also notice that the fundamental statement of "If SMEP is not active,
speculation can go anywhere" is not necessarily true either.

One of the reasons why the BTB can be poisoned from user space in the
first place is because the BTB doesn't have the full range of virtual
address bits for BTB lookup.

But at least on Intel, I think they don't have the full range of
virtual address bits for the _result_ either. The upper bits are
simply taken from the target. So the prediction only looks at - and
only affects - the lower bits of the indirect branch.

Which means that the whole "speculation can go anywhere" is garbage,
at least in general. You can't force the kernel to speculatively jump
to a user space address, because even if you have complete control of
the BTB, you only end up controlling the low bits of the predicted
address, because those are the only ones that exist in the BTB.

That all is obviously very implementation-dependent. You could have a
BTB that uses a small set of bits for the index checking, but the full
set of bits for target.

But since the problem (for the kernel) mostly arises from exactly the
fact that the BTB doesn't have the full bits for indexing, I suspect
the "not full bits in the target" is common too.

                Linus