On Fri, Mar 09, 2018 at 07:06:01PM +0000, Marc Zyngier wrote: > 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... It compiles; it's just not as position independent as it needs to be. IIRC -fno-jump-tables is sufficient to get a clang-compiled KVM booting. It would be much nicer if there was a flag to enforce the use of pc-relative addressing, and forbid absolute addressing, so that we don't have to disable each and every compiler feature that decides to use the latter. Thanks, Mark.
