On Fri, Jun 17, 2011 at 12:04 PM, Renato Golin <rengolin at systemcall.org>wrote:> On 17 June 2011 08:55, Kostya Serebryany <kcc at google.com> wrote: > > I am rather reluctant to add 'generic' code that handles unknown/untested > > platforms because the memory mapping is very platform specific anyway. > > Indeed, but the point of that is more for helping writing > platform-specific versions than actually using it as a general-purpose > routine. Kinda documentation of your intentions on C, which is better > than ASM. > > If you're lucky, it might even work... ;) >Maybe the fallback code should just use a function call. Much simpler for documentation purposes.> > > > > For extreme performance ASAN uses the fixed memory-to-shadow mapping > > (addr>>3)+offset. I guess there are plenty of platforms where this > mapping > > won't work or will require different offset. > > I got a bit confused there, TBH. How do you guarantee that that part > of memory will be allocated?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. 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.> If I'm not mistaken, the Native Client > guys have done a memory place-holder, with enough space pre- and > post-code, is it similar of what you're doing?Not very similar. 64-bit NaCl mmaps 88G of address space. On 64-bit ASAN I need 16384G of RAM, which is a bit too much to mmap.> Or are you using a big > BSS region? > > Depending on how you did it, it might just work on other platforms... > > cheers, > --renato >--kcc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110617/0eeb93c7/attachment.html>
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>
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. > > > 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. >The SEGV handler mmaps large aligned chunks, currently 1M each. (1M of shadow corresponds to 8M of application memory). --kcc> > > -- > 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/a36951f4/attachment.html>
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>