On Sat, Mar 20, 2021 at 01:40:52AM +1100, Daniel Axtens wrote: > Building on the work of Christophe, Aneesh and Balbir, I've ported > KASAN to 64-bit Book3S kernels running on the Radix MMU. > > v11 applies to next-20210317. I had hoped to have it apply to > powerpc/next but once again there are changes in the kasan core that > clash. Also, thanks to mpe for fixing a build break with KASAN off. > > I'm not sure how best to progress this towards actually being merged > when it has impacts across subsystems. I'd appreciate any input. Maybe > the first four patches could go in via the kasan tree, that should > make things easier for powerpc in a future cycle? > > v10 rebases on top of next-20210125, fixing things up to work on top > of the latest changes, and fixing some review comments from > Christophe. I have tested host and guest with 64k pages for this spin. > > There is now only 1 failing KUnit test: kasan_global_oob - gcc puts > the ASAN init code in a section called '.init_array'. Powerpc64 module > loading code goes through and _renames_ any section beginning with > '.init' to begin with '_init' in order to avoid some complexities > around our 24-bit indirect jumps. This means it renames '.init_array' > to '_init_array', and the generic module loading code then fails to > recognise the section as a constructor and thus doesn't run it. This > hack dates back to 2003 and so I'm not going to try to unpick it in > this series. (I suspect this may have previously worked if the code > ended up in .ctors rather than .init_array but I don't keep my old > binaries around so I have no real way of checking.) > > (The previously failing stack tests are now skipped due to more > accurate configuration settings.) > > Details from v9: This is a significant reworking of the previous > versions. Instead of the previous approach which supported inline > instrumentation, this series provides only outline instrumentation. > > To get around the problem of accessing the shadow region inside code we run > with translations off (in 'real mode'), we we restrict checking to when > translations are enabled. This is done via a new hook in the kasan core and > by excluding larger quantites of arch code from instrumentation. The upside > is that we no longer require that you be able to specify the amount of > physically contiguous memory on the system at compile time. Hopefully this > is a better trade-off. More details in patch 6. > > kexec works. Both 64k and 4k pages work. Running as a KVM host works, but > nothing in arch/powerpc/kvm is instrumented. It's also potentially a bit > fragile - if any real mode code paths call out to instrumented code, things > will go boom. > The last time I checked, the changes for real mode, made the code hard to review/maintain. I am happy to see that we've decided to leave that off the table for now, reviewing the series Balbir Singh.
