[LLVMdev] LLVM-based address sanity checker

Renato Golin rengolin at systemcall.org
Fri Jun 17 01:42:35 PDT 2011

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

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



Reclaim your digital rights, eliminate DRM, learn more at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110617/79e22a88/attachment.html>

More information about the llvm-dev mailing list