[LLVMdev] LLVM-based address sanity checker

[Kostya Serebryany]

Hi Chris,

You said "Having functionality like this in mainline would be really
interesting."
Could you suggest us our next steps?
Btw, most our tests already work on Mac 10.6 (32- and 64- bit).

--kcc

On Tue, Jun 21, 2011 at 7:05 PM, Kostya Serebryany <kcc at google.com> wrote:

> Hi,
> What would be our next steps in getting ASan into the LLVM trunk?
> I'd like to do it in two steps, first for the LLVM part with minimal tests
> and then for the run-time library and all tests.
> The current ASan's source repository will probably stay the primary home
> for the run-time library and tests as we plan to use it in non-LLVM
> environments.
>
> Thanks,
>
> --kcc
>
>
> On Fri, Jun 17, 2011 at 4:34 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> 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/20110623/58d359f0/attachment.html>