ASAN runtime asserts in some sbox_integration_tests |
||||
Issue descriptionSee https://bugs.chromium.org/p/chromium/issues/detail?id=783296#c36, but the long and short of it is that these two sbox_integration_tests: ProcessMitigationsTest.CheckWin10DynamicCodeOptOutPolicySuccess (../../sandbox/win/src/process_mitigations_dyncode_unittest.cc:477) ProcessMitigationsTest.CheckWin81DynamicCodePolicySuccess (../../sandbox/win/src/process_mitigations_dyncode_unittest.cc:396) lead to an assert failure in the ASAN runtime: 1:005> g ==98936==AddressSanitizer CHECK failed: C:\b\rr\tmpnsk_yx\w\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common/sanitizer_common_interceptors.inc:6413 "((__interception::real_memcpy)) != (0)" (0x0, 0x0) ==98936==AddressSanitizer CHECK failed: C:\b\rr\tmpnsk_yx\w\src\third_party\llvm\projects\compiler-rt\lib\asan\asan_poisoning.cc:40 "((__interception::real_memset)) != (0)" (0x0, 0x0) It's hard to debug this, as the failing code is in macros. The best way to do it is probably to move the offending code into a function, and compile a custom version of the compiler-rt to link with. It's a mystery why this only happens for these two tests, as it seems all the tests would execute this initialization code. Note that the assert is printed twice, as the CHECK error reporting code trips the problem a second time.
,
Jan 24 2018
Note to self - LLVM build: C:\src\llvm\llvm-ninja-release> "c:\Program Files\CMake\bin\cmake.exe" ../llvm-project/llvm -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS=all ninja -j 56 compiler-rt clang args.gn: clang_base_path = "C:\src\llvm\llvm-ninja-release"
,
May 22 2018
fyi: https://groups.google.com/a/google.com/d/msg/lexan/iP1UWSliKyE/O-g1-h7kAwAJ has some notes on how to build llvm with goma if you want. Your flags look good; you might want to pass -DLLVM_ENABLE_ASSERTIONS=ON too. The clang_base_path bit is documented at https://chromium.googlesource.com/chromium/src/+/lkcr/docs/clang.md#Using-a-custom-clang-binary (but you know about it already)
,
May 22 2018
To be clear, I'm not working on this any time soon, but I wanted to document what I observed. Cutting this one loose for someone else to work on.
,
Jun 18 2018
We made the tot bots 64-bit, so I'll look into this now.
,
Jun 19 2018
This happens because the ASan RTL attempts to allocate RWX memory for trampolines:
if (info.State == MEM_FREE && info.RegionSize >= granularity) {
void *page = ::VirtualAlloc((void*)RoundUpTo(address, granularity),
granularity,
MEM_RESERVE | MEM_COMMIT,
PAGE_EXECUTE_READWRITE);
return page;
}
I guess this process policy makes that VirtualAlloc call fail, ultimately leading to check failure and deadlock.
,
Jun 19 2018
I fixed the ASan deadlock in r335007, and I sent a CL to disable the tests with ASan: https://chromium-review.googlesource.com/c/1105513/
,
Jun 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4091aa049816bbfe0b90630d6732ce0f8629e044 commit 4091aa049816bbfe0b90630d6732ce0f8629e044 Author: Reid Kleckner <rnk@google.com> Date: Tue Jun 19 22:02:57 2018 Disable some dynamic code sandboxing tests with ASan Windows ASan hotpatches executables and allocates RWX code pages, which means we can't intercept memmove/memset, which ASan needs. Reimplementing ASan's interception mechanism to avoid hotpatching is an extended long term project. R=pennymac@chromium.org BUG=805414 Change-Id: I4b05235e5c8abac1055a3ed56a26ca2ba4b7ad22 Reviewed-on: https://chromium-review.googlesource.com/1105513 Reviewed-by: Penny MacNeil <pennymac@chromium.org> Commit-Queue: Reid Kleckner <rnk@chromium.org> Cr-Commit-Position: refs/heads/master@{#568613} [modify] https://crrev.com/4091aa049816bbfe0b90630d6732ce0f8629e044/sandbox/win/src/process_mitigations_dyncode_unittest.cc |
||||
►
Sign in to add a comment |
||||
Comment 1 by siggi@chromium.org
, Jan 24 2018