Re: [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector.
From: Andrey Ryabinin
Date: Thu Jul 10 2014 - 10:05:26 EST
On 07/10/14 01:59, Vegard Nossum wrote:
> On 9 July 2014 23:44, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
>> Dave Hansen <dave.hansen@xxxxxxxxx> writes:
>>> You're also claiming that "KASAN is better than all of
>> better as in finding more bugs, but surely not better as in
>> "do so with less overhead"
>>> CONFIG_DEBUG_PAGEALLOC". So should we just disallow (or hide)
>>> DEBUG_PAGEALLOC on kernels where KASAN is available?
>> I don't think DEBUG_PAGEALLOC/SLUB debug and kasan really conflict.
>> DEBUG_PAGEALLOC/SLUB is "much lower overhead but less bugs found".
>> KASAN is "slow but thorough" There are niches for both.
>> But I could see KASAN eventually deprecating kmemcheck, which
>> is just incredible slow.
> FWIW, I definitely agree with this -- if KASAN can do everything that
> kmemcheck can, it is no doubt the right way forward.
AFAIK kmemcheck could catch reads of uninitialized memory.
KASAN can't do it now, but It should be possible to implementation.
There is such tool for userspace - https://code.google.com/p/memory-sanitizer/wiki/MemorySanitizer
However detection of reads of uninitialized memory will require a different
shadow encoding. Therefore I think it would be better to make it as a separate feature, incompatible with kasan.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/