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>
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/20110621/7816efd1/attachment.html>
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>
On Jun 21, 2011, at 8:05 AM, Kostya Serebryany 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. >Hi Kostya, I haven't had a chance to look at your patch yet, I'm backed up on "big patches". Did you see my review of the safecode patch here? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110718/124515.html I expect to have similar concerns and suggestions for your patch, -Chris