[lkml]   [2014]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger.
On Fri, Nov 21, 2014 at 2:00 AM, Andrew Morton
<> wrote:
> On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov <> wrote:
>> Let me provide some background first.
> Well that was useful. Andrey, please slurp Dmitry's info into the 0/n
> changelog?
> Also, some quantitative info about the kmemleak overhead would be
> useful.
> In this discussion you've mentioned a few planned kasan enhancements.
> Please also list those and attempt to describe the amount of effort and
> complexity levels. Partly so other can understand the plans and partly
> so we can see what we're semi-committing ourselves to if we merge this
> stuff.

The enhancements are:
1. Detection of stack out-of-bounds. This is done mostly in the
compiler. Kernel only needs adjustments in reporting.
2. Detection of global out-of-bounds. Kernel will need to process
compiler-generated list of globals during bootstrap. Complexity is
very low and it is isolated in Asan code.
3. Heap quarantine (delayed reuse of heap blocks). We will need to
hook into slub, queue freed blocks in an efficient/scalable way and
integrate with memory shrinker (register_shrinker). This will be
somewhat complex and touch production kernel code. Konstantin
Khlebnikov wants to make the quarantine available independently of
Asan, as part of slub debug that can be enabled at runtime.
4. Port Asan to slAb.
5. Do various tuning of allocator integration, redzones sizes,
speeding up what is currently considered debug-only paths in
malloc/free, etc.
6. Some people also expressed interest in ARM port.

The user-space Asan codebase is mostly stable for the last two years,
so it's not that we have infinite plans.

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