lkml.org 
[lkml]   [2018]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 00/18] prevent bounds-check bypass via speculative execution
    On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.williams@intel.com> wrote:
    > Quoting Mark's original RFC:
    >
    > "Recently, Google Project Zero discovered several classes of attack
    > against speculative execution. One of these, known as variant-1, allows
    > explicit bounds checks to be bypassed under speculation, providing an
    > arbitrary read gadget. Further details can be found on the GPZ blog [1]
    > and the Documentation patch in this series."
    >
    > This series incorporates Mark Rutland's latest api and adds the x86
    > specific implementation of nospec_barrier. The
    > nospec_{array_ptr,ptr,barrier} helpers are then combined with a kernel
    > wide analysis performed by Elena Reshetova to address static analysis
    > reports where speculative execution on a userspace controlled value
    > could bypass a bounds check. The patches address a precondition for the
    > attack discussed in the Spectre paper [2].
    >
    > A consideration worth noting for reviewing these patches is to weigh the
    > dramatic cost of being wrong about whether a given report is exploitable
    > vs the overhead nospec_{array_ptr,ptr} may introduce. In other words,
    > lets make the bar for applying these patches be "can you prove that the
    > bounds check bypass is *not* exploitable". Consider that the Spectre
    > paper reports one example of a speculation window being ~180 cycles.
    >
    > Note that there is also a proposal from Linus, array_access [3], that
    > attempts to quash speculative execution past a bounds check without
    > introducing an lfence instruction. That may be a future optimization
    > possibility that is compatible with this api, but it would appear to
    > need guarantees from the compiler that it is not clear the kernel can
    > rely on at this point. It is also not clear that it would be a
    > significant performance win vs lfence.
    >
    > These patches also will also be available via the 'nospec' git branch
    > here:
    >
    > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec

    It appears that git.kernel.org has not mirrored out the new branch. In
    the meantime here's an alternative location:

    https://github.com/djbw/linux.git nospec

    If there are updates to these patches they will appear in nospec-v2,
    nospec-v3, etc... branches.

    \
     
     \ /
      Last update: 2018-01-06 20:38    [W:3.569 / U:0.320 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site