+eugenis@ for msan

On Mon, Aug 7, 2017 at 10:33 AM, Kees Cook <keescook@google.com> wrote:

> On Mon, Aug 7, 2017 at 10:24 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > The recent "binfmt_elf: use ELF_ET_DYN_BASE only for PIE" patch:
> > https://github.com/torvalds/linux/commit/eab09532d40090698b05a07c1c87f3
> 9fdbc5fab5
> > breaks user-space AddressSanitizer. AddressSanitizer makes assumptions
> > about address space layout for substantial performance gains. There
> > are multiple people complaining about this already:
> > https://github.com/google/sanitizers/issues/837
> > https://twitter.com/kayseesee/status/894594085608013825
> > https://bugzilla.kernel.org/show_bug.cgi?id=196537
> > AddressSanitizer maps shadow memory at [0x00007fff7000-0x10007fff7fff]
> > expecting that non-pie binaries will be below 2GB and pie
> > binaries/modules will be at 0x55 or 0x7f. This is not the first time
> > kernel address space shuffling breaks sanitizers. The last one was the
> > move to 0x55.
>
> What are the requirements for 32-bit and 64-bit memory layouts for
> ASan currently, so we can adjust the ET_DYN base to work with existing
> ASan?
>


64-bit asan shadow is 0x00007fff8000 - 0x10007fff8000
32-bit asan shadow is 0x20000000 - 0x40000000


% cat dummy.c
int main(){}
% clang -fsanitize=address dummy.c && ASAN_OPTIONS=verbosity=1 ./a.out
 2>&1 | grep '||'
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||
%

% clang -fsanitize=address dummy.c -m32 && ASAN_OPTIONS=verbosity=1 ./a.out
 2>&1 | grep '||'
|| `[0x40000000, 0xffffffff]` || HighMem    ||
|| `[0x28000000, 0x3fffffff]` || HighShadow ||
|| `[0x24000000, 0x27ffffff]` || ShadowGap  ||
|| `[0x20000000, 0x23ffffff]` || LowShadow  ||
|| `[0x00000000, 0x1fffffff]` || LowMem     ||
%





>
> I would note that on 64-bit the ELF_ET_DYN_BASE adjustment avoids the
> entire 2GB space


Correct, but sadly it overlaps with the asan shadow (see above)


> to stay out of the way of 32-bit address-using VMs,
> for example.
>
> What ranges should be avoided currently? We need to balance this
> against the need to keep the PIE away from a growing heap...
>

See above.


>
> > Is it possible to make this change less aggressive and keep the
> > executable under 2GB?
>
> _Under_ 2GB? It's possible we're going to need some VM tunable to
> adjust these things if we're facing incompatible requirements...
>
> ASan does seem especially fragile about these kinds of changes. Can
> future versions of ASan be more dynamic about this?
>

ASan already has the dynamic shadow as an option, and it's default mode
on 64-bit windows, where the kernel is actively hostile to asan.
On Linux, we could enable it by
  clang -fsanitize=address -O dummy.cc -mllvm -asan-force-dynamic-shadow=1
(not heavily tested though).

The problem is that this comes at a cost that we are very reluctant to pay.
Dynamic shadow means one extra load and one extra register stolen per
function,
which increases the CPU usage and code size.



--kcc




>
> -Kees
>
> --
> Kees Cook
> Pixel Security
>