lkml.org 
[lkml]   [2015]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v9 00/17] Kernel address sanitizer - runtime memory debugger.
On 01/21/2015 11:51 AM, Andrey Ryabinin wrote:
> Changes since v8:
> - Fixed unpoisoned redzones for not-allocated-yet object
> in newly allocated slab page. (from Dmitry C.)
>
> - Some minor non-function cleanups in kasan internals.
>
> - Added ack from Catalin
>
> - Added stack instrumentation. With this we could detect
> out of bounds accesses in stack variables. (patch 12)
>
> - Added globals instrumentation - catching out of bounds in
> global varibles. (patches 13-17)
>
> - Shadow moved out from vmalloc into hole between vmemmap
> and %esp fixup stacks. For globals instrumentation
> we will need shadow backing modules addresses.
> So we need some sort of a shadow memory allocator
> (something like vmmemap_populate() function, except
> that it should be available after boot).
>
> __vmalloc_node_range() suits that purpose, except that
> it can't be used for allocating for shadow in vmalloc
> area because shadow in vmalloc is already 'allocated'
> to protect us from other vmalloc users. So we need
> 16TB of unused addresses. And we have big enough hole
> between vmemmap and %esp fixup stacks. So I moved shadow
> there.

I'm not sure which new addition caused it, but I'm getting tons of
false positives from platform drivers trying to access memory they
don't "own" - because they expect to find hardware there.

I suspect we'd need to mark that memory region somehow to prevent
accesses to it from triggering warnings?


Thanks,
Sasha


\
 
 \ /
  Last update: 2015-01-22 01:41    [W:1.591 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site