+eugenis@ for msan
On Mon, Aug 7, 2017 at 10:33 AM, Kees Cook <keescook@xxxxxxxxxx> wrote:
On Mon, Aug 7, 2017 at 10:24 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> 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] What are the requirements for 32-bit and 64-bit memory layouts for
> 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.
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
