lkml.org 
[lkml]   [2018]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
    On Sat, Jan 6, 2018 at 11:25 AM, Alexei Starovoitov
    <alexei.starovoitov@gmail.com> wrote:
    > On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
    >> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
    >> <alexei.starovoitov@gmail.com> wrote:
    >> [..]
    >> >> retpoline is variant-2, this patch series is about variant-1.
    >> >
    >> > that's exactly the point. Don't slow down the kernel with lfences
    >> > to solve variant 1. retpoline for 2 is ok from long term kernel
    >> > viability perspective.
    >> >
    >>
    >> Setting aside that we still need to measure the impact of these
    >> changes the end result will still be nospec_array_ptr() sprinkled in
    >> various locations. So can we save the debate about what's inside that
    >> macro on various architectures and at least proceed with annotating
    >> the problematic locations? Perhaps we can go a step further and have a
    >> config option to switch between the clever array_access() approach
    >> from Linus that might be fine depending on the compiler, and the
    >> cpu-vendor-recommended not to speculate implementation of
    >> nospec_array_ptr().
    >
    > recommended by panicing vendors who had no better ideas?
    > Ohh, speculation is exploitable, let's stop speculation.
    > Instead of fighting it we can safely steer it where it doesn't leak
    > kernel data. AND approach is doing exactly that.
    > It probably can be made independent of compiler choice to use setbe-like insn.

    Right, when that 'probably' is 'certainly' for the architecture you
    care about just update the nospec_array_ptr() definition at that
    point.

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