| Date | Wed, 21 Jan 2015 19:22:42 -0500 | From | Sasha Levin <> | Subject | Re: [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
|