lkml.org 
[lkml]   [2018]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs
    From
    Date
    On 22.03.2018 16:46, Dave Hansen wrote:
    > On 03/21/2018 05:09 PM, Maciej S. Szmigiero wrote:
    >> As far as I understand the issue this should provide a good protection
    >> for userspace processes that were recompiled with retpolines as they
    >> won't have any indirect jumps and calls.
    >
    > Instead of saying "good protection", let's just say that it could
    > mitigate attacks that require consumption of attacker-placed RSB entries.

    All right.

    >>> Do you perhaps want to do RSB manipulation in lieu of IBPB when
    >>> switching *to* a non-dumpable process and IBPB is not available?
    >>
    >> Is it worth differentiating such processes in this case?
    >> IBPB is supposed to be very expensive so certainly it is worthwhile
    >> to do it only for high-value processes (=non-dumpable).
    >>
    >> However, it is unlikely that existing RSB entries from the previous
    >> task match the new task call stack anyway.
    >> We already do unconditional RSB-filling-on-context-switch in many
    >> cases.
    >
    > I think this case is a bit too obscure and theoretical to complicate the
    > kernel with it. You need an unmitigated processor, a
    > userspace-to-userspace attack that manages to satisfy the five "exploit
    > composition" steps of Spectre/V2[1], and an application that has been
    > retpoline-mitigated.
    >
    > While RSB manipulation is almost certainly less onerous than IBPB, it's
    > still going to hurt context-switch rates, especially if applied
    > indiscriminately like this patch does.
    >
    > So, I totally agree with your analysis about the theoretical potential
    > for an issue, I'm just not really convinced the fix is worth it.

    Yes, Spectre v2 looks really hard to exploit, but this doesn't mean the
    kernel shouldn't do its best to mitigate it.

    As I wrote two messages ago, basing on the Intel guidance document you
    linked above as "[1]" I think that the mitigation introduced by this
    patch should not be done on Intel CPUs, however, since that document
    clearly suggests that this may not be enough to cover the issue.
    And I think we shouldn't give people a false sense of security.

    Maciej

    \
     
     \ /
      Last update: 2018-03-24 00:12    [W:7.879 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site