On Thu, Nov 19, 2015 at 11:19:23AM +0300, Maxim Ostapenko wrote:
> Hi!
>
> Since the last sanitizer library merge to GCC happened, some new useful
> features were applied upstream. In particular, the most significant are:
>
> * The shadow offset for ASan was unified on Aarch64 for 39 and 42 VMAs
> (http://reviews.llvm.org/D13782). AFAU, this change wouldn't require any
> additional support from compiler side, because the shadow offset is the same
> as for 39-bit VMA (36) .
> * Optional ASan recovery functionality was merged to sanitizer library
> (http://reviews.llvm.org/D12318). This feature seems to be very helpful in
> complex systems where we may want to proceed to work even in case of bug was
> detected. However, to access this functionality, we'll need to implement new
> asan_report_{store, load}{1, 2, 4, 8, 16, N}_noabort callbacks in compiler.
> This is probably unacceptable for stage 3.
No, those are already there (for -fsanitize{,-recover}=kernel-address).
IMHO all you need is remove:
if (opts->x_flag_sanitize_recover & SANITIZE_USER_ADDRESS)
error_at (loc, "-fsanitize-recover=address is not supported");
in opts.c (finish_options), and in asan.c (asan_expand_check_ifn)
change
bool recover_p
= (flag_sanitize & flag_sanitize_recover & SANITIZE_KERNEL_ADDRESS) != 0;
to say:
bool recover_p;
if (flag_sanitize & SANITIZE_USER_ADDRESS)
recover_p = (flag_sanitize_recover & SANITIZE_USER_ADDRESS) != 0;
else
recover_p = (flag_sanitize_recover & SANITIZE_KERNEL_ADDRESS) != 0;
(plus add some testsuite coverage).
This is small enough change that I'm ok with an exception for this.
> I think it would be nice to have unified shadow offset on Aarch64 for 39 and
> 42 VMAs even in GCC 6 (enabling ASan recovery would be nice too, but it's
> much harder).
>
> So, my question is: is it acceptable to backport these features from
> upstream without touching compiler side? If so, I see two options here:
>
> - Perform sanitizer library merge to GCC without changing compiler side.
And at this point I also prefer the above, rather than cherry-picking, of
course later on in the process cherry-picking will be desirable instead.
> - Cherry-pick the patch for AArch64 on top of current trunk.
Jakub
