On Wed, Dec 4, 2019 at 2:12 PM Qian Cai <cai@xxxxxx> wrote: > > > > > On Dec 4, 2019, at 7:22 AM, Petr Mladek <pmladek@xxxxxxxx> wrote: > > > > IMHO, a generic distro debug kernel could not enable debugging > > options that would significantly slow down the kernel. Most users > > would refuse using such kernels. Also they might slow down > > the system to the point that many problems won't be visible. > > > > For example, I do not see KASAN enabled in SUSE debug kernel. > > I guess that it will be the same with KMSAN. These options > > can be enabled in custom kernels when debugging particular > > problems. > > No, KASAN is one of most important debug options to find general issues. It was actually used in many debug kernels like those in Google. In contrast, it will find many issues compared to without even though the performance would suffer in some degrees. > > I would even argue that since KASAN is so valuable that it is also desirable to get KMSAN to work together with KASAN by improving the compilers. Otherwise, it is a struggling to choose between KASAN and KMSAN for general debug kernels as KASAN could also cover a subset of KMSAN coverage. Turns out it was fairly easy to make KMSAN work with lockdep, sorry for the noise. I'll send the updated patch that disables instrumentation of kernel/locking/lockdep.c in v4. While on this, I want to make a point on KMSAN features that seem to be misunderstood. KMSAN uses precise bit-to-bit shadow mapping and compiler instrumentation for shadow tracking to tell whether a value is used in a comparison, pointer dereference or is copied to hardware or userspace. As long as the use of such value doesn't cause an immediate crash or a memory corruption, KASAN is simply unable to detect such bugs. Neither are any other existing tools, although they may also report errors later, after the use of uninitialized values. There's a list of bugs found by syzbot running KMSAN (https://syzkaller.appspot.com/upstream/fixed?manager=ci-upstream-kmsan-gce), and I would say more than a hundred of those is unique to KMSAN. One can think of KMSAN as a _fast_ replacement of kmemcheck. Unfortunately, the latter bit-rotted at some point and was deleted from the kernel (I don't think distro debug kernels ever used it though). >From our experience building userspace tools, making KMSAN and KASAN work together isn't worth it. The resulting monster will be slower than any of the two tools and will be using more memory than both of them together. This means that anyone who's using at least two machines for fuzzing or continuous integration will prefer running two different tools on them instead of running KMSAN+KASAN together on every machine. That said, I'll try my best to keep existing low-overhead debug configs working with KMSAN, but it still won't solve the need of running orthogonal kernel configs for testing. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
