lkml.org 
[lkml]   [2014]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger.
    On 11/20/2014 12:03 PM, Ingo Molnar wrote:
    >
    > * Andrey Ryabinin <ryabinin.a.a@gmail.com> wrote:
    >
    >> I've counted 16:
    >>
    >> aab515d (fib_trie: remove potential out of bound access)
    >> 984f173 ([SCSI] sd: Fix potential out-of-bounds access)
    >> 5e9ae2e (aio: fix use-after-free in aio_migratepage)
    >> 2811eba (ipv6: udp packets following an UFO enqueued packet need also
    >> be handled by UFO)
    >> 057db84 (tracing: Fix potential out-of-bounds in trace_get_user())
    >> 9709674 (ipv4: fix a race in ip4_datagram_release_cb())
    >> 4e8d213 (ext4: fix use-after-free in ext4_mb_new_blocks)
    >> 624483f (mm: rmap: fix use-after-free in __put_anon_vma)
    >> 93b7aca (lib/idr.c: fix out-of-bounds pointer dereference)
    >> b4903d6 (mm: debugfs: move rounddown_pow_of_two() out from do_fault path)
    >> 40eea80 (net: sendmsg: fix NULL pointer dereference)
    >> 10ec947 (ipv4: fix buffer overflow in ip_options_compile())
    >> dbf20cb2 (f2fs: avoid use invalid mapping of node_inode when evict meta inode)
    >> d6d86c0 (mm/balloon_compaction: redesign ballooned pages management)
    >>
    >> + 2 recently found, seems minor:
    >> http://lkml.kernel.org/r/1415372020-1871-1-git-send-email-a.ryabinin@samsung.com
    >> (sched/numa: Fix out of bounds read in sched_init_numa())
    >>
    >> http://lkml.kernel.org/r/1415458085-12485-1-git-send-email-ryabinin.a.a@gmail.com
    >> (security: smack: fix out-of-bounds access in smk_parse_smack())
    >>
    >> Note that some functionality is not yet implemented in this
    >> patch set. Kasan has possibility to detect out-of-bounds
    >> accesses on global/stack variables. Neither
    >> kmemcheck/debug_pagealloc or slub_debug could do that.
    >>
    >>> That's in a 20-year-old code base, so one new minor bug discovered per
    >>> three years? Not worth it!
    >>>
    >>> Presumably more bugs will be exposed as more people use kasan on
    >>> different kernel configs, but will their number and seriousness justify
    >>> the maintenance effort?
    >>>
    >>
    >> Yes, AFAIK there are only few users of kasan now, and I guess that
    >> only small part of kernel code
    >> was covered by it.
    >> IMO kasan shouldn't take a lot maintenance efforts, most part of code
    >> is isolated and it doesn't
    >> have some complex dependencies on in-kernel API.
    >> And you could always just poke me, I'd be happy to sort out any issues.
    >>
    >>> If kasan will permit us to remove kmemcheck/debug_pagealloc/slub_debug
    >>> then that tips the balance a little. What's the feasibility of that?
    >>>
    >>
    >> I think kasan could replace kmemcheck at some point.
    >
    > So that angle sounds interesting, because kmemcheck is
    > essentially unmaintained right now: in the last 3 years since
    > v3.0 arch/x86/mm/kmemcheck/ has not seen a single kmemcheck
    > specific change, only 4 incidental changes.
    >
    > kmemcheck is also very architecture bound and somewhat fragile
    > due to having to decode instructions, so if generic, compiler
    > driven instrumentation can replace it, that would be a plus.
    >

    GCC already supports address sanitizer on x86_32/x86_64/arm/arm64/rs6000,
    and adding compiler's support for any other architecture is trivial.

    Per-arch work on kernel-side maybe is not trivial, but there is nothing complex either.
    It's much more simpler then kmemcheck.




    \
     
     \ /
      Last update: 2014-11-20 14:21    [W:4.268 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site