4 ms·

Aside: static analysis is a great initial effort but to really get confidence you should use techniques like sanitizers (MSan in this case) or valgrind. (This

Aside: static analysis is a great initial effort but to really get confidence you should use techniques like sanitizers (MSan in this case) or valgrind. (This is general advice, not always applicable to kernels).

mhh__ 8y ago
You should really use both, however they are only a tool: I don't have any numbers but I imagine Sanitizers have a good detection rate, but one should still write code defensively. There are too many horror stories, be they lethal or expensive, to be risky about memory. Not a kernel developer: Can you test Kernel code with a sanitizer (if that sanitizer doesn't work in a compiled kernel) by compiling into and using the code as blob in userspace code with mocks (Or whatever, unless it's just utility that doesn't need anything other than an interface)?
- saagarjha 8y ago
  Yup, Address Sanitizer can hide or fail to catch bugs occasionally.
- wyldfire 8y ago
  > but one should still write code defensively. I'm not sure what this means. You should not write your code any differently regardless of whether you used a sanitizer to help gain confidence in your implementation. You should not use sanitizers in production (at least not the current generation). > Can you test Kernel code with a sanitizer In fact you can! Both UBSan [1] and ASan [2] are in use to root out bugs in linux. [1] https://www.kernel.org/doc/html/v4.14/dev-tools/ubsan.html https://www.kernel.org/doc/html/v4.14/dev-tools/ubsan.html [2] https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html
- muricula 8y ago
  Linux has support for kernel ASAN and I think UBSAN too. User mode linux is a also thing and does roughly what you described, and I think you can run it under valgrind too.
  - monocasa 8y ago
    To be fair, UML runs at such a low level (raw syscalls rather than calls to, for instance, malloc and free) that it really limits what valgrind can tell you.
wtracy 8y ago
By msan, are you referring to this? https://clang.llvm.org/docs/MemorySanitizer.html https://clang.llvm.org/docs/MemorySanitizer.html (I'd never heard of the tool before.)
- rurban 8y ago
  Yes, this is msan. All the clang sanitizers have handy names, like tsan, msan, asan, ubsan, ksan. And they even made it to gcc.
  - corndoge 8y ago
    IIRC they were in GCC first and later ported to clang because it was too annoying for Google to continue to maintain them in GCC.
    - rurban 8y ago
      As far as I know Kostya he started by improving Helgrind as valgrind plugin in 2008: the first ThreadSanitizer (as project data-race-test) https://storage.googleapis.com/pub-tools-public-publication-data/pdf/35604.pdf https://storage.googleapis.com/pub-tools-public-publication-... which was a harder problem than oob checks. But it was still too slow, and they started with tsan and asan as clang plugin. Years later they ported it to gcc. gcc started then becoming more plugin friendly.

mhh__ 8y ago

You should really use both, however they are only a tool: I don't have any numbers but I imagine Sanitizers have a good detection rate, but one should still write code defensively. There are too many horror stories, be they lethal or expensive, to be risky about memory. Not a kernel developer: Can you test Kernel code with a sanitizer (if that sanitizer doesn't work in a compiled kernel) by compiling into and using the code as blob in userspace code with mocks (Or whatever, unless it's just utility that doesn't need anything other than an interface)?

saagarjha 8y ago
Yup, Address Sanitizer can hide or fail to catch bugs occasionally.
wyldfire 8y ago
> but one should still write code defensively. I'm not sure what this means. You should not write your code any differently regardless of whether you used a sanitizer to help gain confidence in your implementation. You should not use sanitizers in production (at least not the current generation). > Can you test Kernel code with a sanitizer In fact you can! Both UBSan [1] and ASan [2] are in use to root out bugs in linux. [1] https://www.kernel.org/doc/html/v4.14/dev-tools/ubsan.html https://www.kernel.org/doc/html/v4.14/dev-tools/ubsan.html [2] https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html
muricula 8y ago
Linux has support for kernel ASAN and I think UBSAN too. User mode linux is a also thing and does roughly what you described, and I think you can run it under valgrind too.
- monocasa 8y ago
  To be fair, UML runs at such a low level (raw syscalls rather than calls to, for instance, malloc and free) that it really limits what valgrind can tell you.

wtracy 8y ago

By msan, are you referring to this? https://clang.llvm.org/docs/MemorySanitizer.html https://clang.llvm.org/docs/MemorySanitizer.html (I'd never heard of the tool before.)

rurban 8y ago
Yes, this is msan. All the clang sanitizers have handy names, like tsan, msan, asan, ubsan, ksan. And they even made it to gcc.
- corndoge 8y ago
  IIRC they were in GCC first and later ported to clang because it was too annoying for Google to continue to maintain them in GCC.
  - rurban 8y ago
    As far as I know Kostya he started by improving Helgrind as valgrind plugin in 2008: the first ThreadSanitizer (as project data-race-test) https://storage.googleapis.com/pub-tools-public-publication-data/pdf/35604.pdf https://storage.googleapis.com/pub-tools-public-publication-... which was a harder problem than oob checks. But it was still too slow, and they started with tsan and asan as clang plugin. Years later they ported it to gcc. gcc started then becoming more plugin friendly.