Kernel Address Sanitizer (KASAN)
Address Sanitizer is a remarkable feature that is part of the compilers gcc and clang. I make heavy use of it and it can uncover many memory access bugs that would otherwise be hard to find.
What may be lesser known is that there is also the possibility to use Address Sanitizer for the Linux Kernel. It is available as an option since version 4.0.
I recently tried for the first time to boot a kernel with Kernel Addres Sanitizer (KASAN). There are a few things to consider. Appart from the option CONFIG_KASAN one should also set CONFIG_STACKTRACE. There are two variants how KASAN can be enabled, CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. The latter seems to be preferrable, it's faster, but it creates a larger kernel binary and requires a relatively recent gcc version (5.0 or later).
To my surprise just booting a kernel with KASAN already showed a number of warnings about out of bounds errors. Unlike normal ASAN these errors don't cause a crash (that would be quite inconvenient in the kernel). Instead they just print a warning in the dmesg log. Also by itself the kernel is not able to print an error message with line numbers. One needs to pass the output to a script that is available here.
Most of the warnings came from a preprocessor macro in the Intel GPU driver. I spend some time fixing the issue and had a working patch ready. Then I found out that it was already fixed in the current git code... (Remember: Always check if code is already fixed in git if you try to fix a bug.)
Anyway, having fixed that issue silenced most of the warnings, but a few remained. I could track them down to a wrong use of a counter variable in a nested loop. This loop was supposed to check the correct sorting of a table of commands. However it turned out that the tables weren't properly sorted and the fix made the kernel unbootable. After some discussions with the Intel driver developers I was able to finally fix the issue with two patches which have just been merged into the main kernel tree (they are in 4.3-rc1).
Given that just booting the kernel with KASAN enabled was enough to uncover some bugs indicates that not enough people have tested it yet. I also tried some kernel fuzzing tools with KASAN enabled (perf_fuzzer and trinity) and tried to mount a couple of corrupted filesystem images generated by american fuzzy lop. That didn't turn up any further bugs.
What may be lesser known is that there is also the possibility to use Address Sanitizer for the Linux Kernel. It is available as an option since version 4.0.
I recently tried for the first time to boot a kernel with Kernel Addres Sanitizer (KASAN). There are a few things to consider. Appart from the option CONFIG_KASAN one should also set CONFIG_STACKTRACE. There are two variants how KASAN can be enabled, CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. The latter seems to be preferrable, it's faster, but it creates a larger kernel binary and requires a relatively recent gcc version (5.0 or later).
To my surprise just booting a kernel with KASAN already showed a number of warnings about out of bounds errors. Unlike normal ASAN these errors don't cause a crash (that would be quite inconvenient in the kernel). Instead they just print a warning in the dmesg log. Also by itself the kernel is not able to print an error message with line numbers. One needs to pass the output to a script that is available here.
Most of the warnings came from a preprocessor macro in the Intel GPU driver. I spend some time fixing the issue and had a working patch ready. Then I found out that it was already fixed in the current git code... (Remember: Always check if code is already fixed in git if you try to fix a bug.)
Anyway, having fixed that issue silenced most of the warnings, but a few remained. I could track them down to a wrong use of a counter variable in a nested loop. This loop was supposed to check the correct sorting of a table of commands. However it turned out that the tables weren't properly sorted and the fix made the kernel unbootable. After some discussions with the Intel driver developers I was able to finally fix the issue with two patches which have just been merged into the main kernel tree (they are in 4.3-rc1).
Given that just booting the kernel with KASAN enabled was enough to uncover some bugs indicates that not enough people have tested it yet. I also tried some kernel fuzzing tools with KASAN enabled (perf_fuzzer and trinity) and tried to mount a couple of corrupted filesystem images generated by american fuzzy lop. That didn't turn up any further bugs.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Yury Gribov on :