lkml.org 
[lkml]   [2018]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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@infradead.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

    \
     
     \ /
      Last update: 2018-01-14 23:19    [W:3.406 / U:0.612 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site