[LLVMdev] LLVM-based address sanity checker

[Kostya Serebryany]

On Fri, Jun 17, 2011 at 12:42 PM, Renato Golin <rengolin at systemcall.org>wrote:

> On 17 June 2011 09:14, Kostya Serebryany <kcc at google.com> wrote:
>
>> Maybe the fallback code should just use a function call. Much simpler for
>> documentation purposes.
>
>
> Sounds good.
>
>
> On 32-bit, the shadow region is:
>>  [0x28000000, 0x3fffffff] HighShadow [0x24000000, 0x27ffffff] ShadowGap [0x20000000,
>> 0x23ffffff] LowShadow
>>
>> This is 0.5G total. So, I mmap all these three shadow subregions and
>> 'mprotect' the ShadowGap.
>> This is done at startup. If the mmap fails, an assert will fire.
>>
>
>
> I see. On embedded platforms that won't work with all cases. Most
> implementations have fragmented memory, memory mapped I/O, secure zones,
> etc. Depending on what you're trying to do, mmap will work but writing to
> memory won't.
>
> On ARM world, SoC designers can come up with any number of configurations,
> which makes a generic implementation impossible. You'll need some kind of
> tablegen to define writeable regions and how to map between memory and
> shadow. Manufacturers generally provide this information when you buy the
> kit.
>
> But again, most OSes should take care of that for you, so that's only
> relevant for bare-metal applications.
>
>
>
>
>>
>> On 64-bit, the shadow looks like this:
>>  [0x0000140000000000, 0x00001fffffffffff] HighShadow [0x0000120000000000,
>> 0x000013ffffffffff] ShadowGap [0x0000100000000000, 0x000011ffffffffff]LowShadow
>>
>> This is quite a lot, I can not mmap/mprotect this thing.
>> So, I basically *hope* that it won't be used by anyone but the ASAN run
>> time (of course, there are asserts here and there to check it).
>> When some part of the shadow region is being written to (when we poison
>> memory), SEGV happens and the SEGV handler mmaps the required region.
>>
>
> Ok, if you allocate big enough regions you shouldn't need to SEGV that
> often.
>

The SEGV handler mmaps large aligned chunks, currently 1M each. (1M of
shadow corresponds to 8M of application memory).

--kcc


>
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110617/a36951f4/attachment.html>