On 09/03/18 18:42, Andrey Konovalov wrote: > On Fri, Mar 9, 2018 at 7:32 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> Well, that's not quite how it works. KVM is an integral part of the >> kernel, and I don't really want to have to deal with regression (not to >> mention that KVM is an essential tool in our testing infrastructure). >> >> You could try and exclude KVM from the instrumentation (which we already >> have for invasive things such as KASAN), but I'm afraid that having a >> debugging option that conflicts with another essential part of the >> kernel is not an option. >> >> I'm happy to help you with that though. >> > > Hm, KHWASAN instruments the very same parts of the kernel that KASAN > does (it reuses the same flag). I've checked, I actually have > CONFIG_KVM enabled in my test build, however I haven't tried to test > KVM yet. I'm planning to perform extensive fuzzing of the kernel with > syzkaller, so if there's any crashes caused by KHWASAN in kvm code > I'll see them. However if some bugs don't manifest as crashes, that > would be a difficult thing to detect for me. Well, if something is wrong in KVM, it usually manifests itself extremely quickly, and takes the whole box with it. I have the ugly feeling that feeding coloured pointers to KVM is going to be a fun ride though. Also, last time I checked Clang couldn't even compile KVM correctly. Hopefully, things have changed... Thanks, M. -- Jazz is not dead. It just smells funny...
