Yury Gribov via llvm-dev
2015-Sep-25 10:27 UTC
[llvm-dev] Dynamic VMA in Sanitizers for AArch64
On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev wrote:> On Fri, Sep 25, 2015 at 01:19:48AM -0700, Renato Golin wrote: >> After long talks with lots of people, I think we have a winning >> strategy to deal with the variable nature of VMA address in AArch64. >> It seems that the best way forward is to try the dynamic calculation >> at runtime, evaluate the performance, and then, only if the hit is too >> great, think about compile-time alternatives. I'd like to know if >> everyone is in agreement, so we could get cracking. > > You mean you want a dynamic shadow offset on aarch64 as opposed to > fixed kAArch64_ShadowOffset64 (1UL << 36) one? > I think this is completely unnecessary, all you need to change is > libsanitizer internals IMNSHO, all that is needed is to make runtime > decisions during libasan initialization on the memory layout, and > also (because 39 bit VMA is too slow), dynamic decision whether to use > 32-bit or 64-bit allocator. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 > for details.Added kcc. FYI optional dynamic offset would also help in not-so-rare situations when ASan's shadow range is stolen by early constructors in unsanitized libraries. -Y
Yury Gribov via llvm-dev
2015-Sep-25 10:28 UTC
[llvm-dev] Dynamic VMA in Sanitizers for AArch64
On 09/25/2015 01:27 PM, Yury Gribov wrote:> On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev wrote: >> On Fri, Sep 25, 2015 at 01:19:48AM -0700, Renato Golin wrote: >>> After long talks with lots of people, I think we have a winning >>> strategy to deal with the variable nature of VMA address in AArch64. >>> It seems that the best way forward is to try the dynamic calculation >>> at runtime, evaluate the performance, and then, only if the hit is too >>> great, think about compile-time alternatives. I'd like to know if >>> everyone is in agreement, so we could get cracking. >> >> You mean you want a dynamic shadow offset on aarch64 as opposed to >> fixed kAArch64_ShadowOffset64 (1UL << 36) one? >> I think this is completely unnecessary, all you need to change is >> libsanitizer internals IMNSHO, all that is needed is to make runtime >> decisions during libasan initialization on the memory layout, and >> also (because 39 bit VMA is too slow), dynamic decision whether to use >> 32-bit or 64-bit allocator. See >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 >> for details. > > Added kcc. > > FYI optional dynamic offset would also help in not-so-rare situations > when ASan's shadow range is stolen by early constructors in unsanitized > libraries.And - we'll finally be able to run ASan under Valgrind)
Evgenii Stepanov via llvm-dev
2015-Sep-25 17:38 UTC
[llvm-dev] Dynamic VMA in Sanitizers for AArch64
Jakub makes a good point, are you sure that there is no single shadow offset value that works for all VMA variants? What exactly breaks when 1<<36 is used on 42-bit VMA? On Fri, Sep 25, 2015 at 3:28 AM, Yury Gribov via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 09/25/2015 01:27 PM, Yury Gribov wrote: >> >> On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev wrote: >>> >>> On Fri, Sep 25, 2015 at 01:19:48AM -0700, Renato Golin wrote: >>>> >>>> After long talks with lots of people, I think we have a winning >>>> strategy to deal with the variable nature of VMA address in AArch64. >>>> It seems that the best way forward is to try the dynamic calculation >>>> at runtime, evaluate the performance, and then, only if the hit is too >>>> great, think about compile-time alternatives. I'd like to know if >>>> everyone is in agreement, so we could get cracking. >>> >>> >>> You mean you want a dynamic shadow offset on aarch64 as opposed to >>> fixed kAArch64_ShadowOffset64 (1UL << 36) one? >>> I think this is completely unnecessary, all you need to change is >>> libsanitizer internals IMNSHO, all that is needed is to make runtime >>> decisions during libasan initialization on the memory layout, and >>> also (because 39 bit VMA is too slow), dynamic decision whether to use >>> 32-bit or 64-bit allocator. See >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 >>> for details. >> >> >> Added kcc. >> >> FYI optional dynamic offset would also help in not-so-rare situations >> when ASan's shadow range is stolen by early constructors in unsanitized >> libraries. > > > And - we'll finally be able to run ASan under Valgrind) > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev