2015-01-22 8:34 GMT+03:00 Andrey Ryabinin <ryabinin.a.a@gmail.com>:
> 2015-01-22 3:22 GMT+03:00 Sasha Levin <sasha.levin@oracle.com>:
>> 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.
>>
>
> To be sure, that this is really false positives, could you try with
> patches in attachment?

Attaching properly formed patches