[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.
>

I implemented the asm-free way to report warnings as an option to the llvm
instrumentation pass (uses a call to run-time).
It generates more code, it also creates prologue/epilogue in otherwise leaf
functions.
Such mode may still be useful if for whatever reason we can not use SIGILL.

Default (use ud2):
  402ed5:       48 89 d8                mov    %rbx,%rax  << move the
address to rax
  402ed8:       0f 0b                   ud2a              << crash
  402eda:       52                      push   %rdx       << encode is_write
and size in the opcode
(note: with a good disassembler and some work we can leave just ud2 or
equivalent)

-mllvm -asan-use-call
  402ed5:       48 89 df                mov    %rbx,%rdi  << address is the
paremeter to __asan_report_error_2
  402ed8:       e8 53 69 00 00          callq  409830
<__asan_report_error_2>  << is_write and size is encoded in the function
name


--kcc


>
>
> 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/84ede3fc/attachment.html>