[LLVMdev] LLVM-based address sanity checker

[Renato Golin]

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.


-- 
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/79e22a88/attachment.html>