On Sat, Jan 6, 2018 at 11:25 AM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 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@xxxxxxxxx> 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.
