On Sat, 6 Jan 2018, Alexei Starovoitov 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. For one particular architecture and that's not a solution for generic code. Aside of that I fundamentally disagree with your purely performance optimized argumentation. We need to make sure that we have a solution which kills the problem safely and then take it from there. Correctness first, optimization later is the rule for this. Better safe than sorry. Thanks, tglx
