Fri, Jun 18
Thu, Jun 17
Wed, Jun 16
Tue, Jun 15
Mon, Jun 14
Fri, Jun 11
- Fix clang test failure on Windows.
Wed, Jun 9
- - Address nits.
- Privatize new member variables.
- Rename flag as experimental.
- Refactor and simplify code.
- Apply mask to base tag only.
- Enable some compiler-rt stack tests on x86.
- Add IR tests.
Mon, Jun 7
I've addressed most comments locally; commandeering to prevent wasting Xiang's time addressing the feedback.
Fri, Jun 4
Can we reuse the old https://reviews.llvm.org/D103304? It will make it easier to see the patch history.
Thu, Jun 3
Wed, Jun 2
Thanks for the update. I'll take a closer look tomorrow and try testing locally. You can also use the new buildbot script to test in QEMU (see inline comment below).
- Ensure LLD is built prior to testing HWASan.
- Refactor git clone functionality into a helper function.
- Use single function for both QEMU builds.
- Shorten emulator prefix to single env var.
Tue, Jun 1
Thu, May 27
Tests pass locally.
Could we put this diff in the other review? It will be easier to see what's changed that way. (You might need to re-open that review to update the diff).
Wed, May 26
Multiples tests are failing on the bots: https://lab.llvm.org/buildbot/#/builders/75/builds/6122/steps/7/logs/stdio
Tue, May 25
This patch appears to have caused a performance regression on the buildbots: https://lab.llvm.org/buildbot/#/builders/105/builds/10180
Mon, May 24
2 In fact, We can divide it into two steps, Step 1 is "Tag correctness checking", Step 2 is "Hardware supporting point with tag".The option "ClUntagPointer" can help us first testing the Step 1. For example: we write 7 in to int *p, for HWASAN, we do 2 things: Step1: Checking tag of p : call void @__hwasan_store4 (p_tagged) // Checking tag is correct or not Step2: Write 7 into mem: *p_tagged = 7 // Need Hardware supporting. But if we use "ClUntagPointer" change "*p_tagged = 7" --> "*p = 7", we can run the program, and test Step 1 for HWASAN. For HWASAN, Most code in compiler and compiler-rt is doing work for Step 1. So we can use "ClUntagPointer" first test it. After we make sure Step 1 is OK, when the Hardware/OS is ready, we just need to totally/really enable HWASAN by just, I think, updating the system call in InitPrctl.
Please remove libMutagen.a from the diff before landing since we don't have libFuzzer.a in the current tree either.
May 20 2021
Hi Xiang, thanks for the patch.
May 18 2021
May 17 2021
We started seeing test failures in our Windows builds in Fuchsia after this patch.FAILED: compiler-rt/lib/hwasan/CMakeFiles/RTHwasanAliases.aarch64.dir/hwasan_interceptors.cpp.o C:\b\s\w\ir\x\w\staging\llvm_build\.\bin\clang++.exe --target=aarch64-unknown-linux-gnu --sysroot=C:/b/s/w/ir/x/w/cipd/linux -DHWASAN_WITH_INTERCEPTORS=1 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IC:/b/s/w/ir/x/w/llvm-project/compiler-rt/lib/hwasan/.. --target=aarch64-unknown-linux-gnu -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=C:/b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins=../staging/llvm_build/runtimes/runtimes-aarch64-unknown-linux-gnu-bins -ffile-prefix-map=C:/b/s/w/ir/x/w/llvm-project/= -no-canonical-prefixes -Wall -std=c++14 -Wno-unused-parameter -O2 -g -DNDEBUG -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -nostdinc++ -fno-rtti -fPIC -ffreestanding -DHWASAN_ALIASING_MODE -UNDEBUG -MD -MT compiler-rt/lib/hwasan/CMakeFiles/RTHwasanAliases.aarch64.dir/hwasan_interceptors.cpp.o -MF compiler-rt\lib\hwasan\CMakeFiles\RTHwasanAliases.aarch64.dir\hwasan_interceptors.cpp.o.d -o compiler-rt/lib/hwasan/CMakeFiles/RTHwasanAliases.aarch64.dir/hwasan_interceptors.cpp.o -c C:/b/s/w/ir/x/w/llvm-project/compiler-rt/lib/hwasan/hwasan_interceptors.cpp In file included from C:/b/s/w/ir/x/w/llvm-project/compiler-rt/lib/hwasan/hwasan_interceptors.cpp:18: C:/b/s/w/ir/x/w/llvm-project/compiler-rt/lib/hwasan/hwasan.h:41:6: error: Aliasing mode is only supported on x86_64
The error message to the full build:
@morehouse do you have any idea?
May 14 2021
Moving this to github.com/google/sanitizers after offline discussion.
May 13 2021
- Rename flag to -fsanitize-hwaddress-experimental-aliasing.
- Remove diffbase.
- Use -fexperimental-sanitize-hwaddress-aliasing instead of -mlam.
- Rebase onto D102288.
- Refactor to make LAM the default runtime.
- Use alias runtime if specified.
- Use -mlam option instead of -fsanitize=lam.
- Guard new prctl() API under INTEL_LAM.
May 12 2021
Would it be simple if module constructor of initialized code just sets some global or call init function to switch HWASAN into LAM so we can have the same runtime?
May 11 2021
- Add comment regarding new prctl() API.
May 7 2021
Thanks for notifying. I've submitted https://reviews.llvm.org/rGf09414499c47 to address the Windows bot.
May 6 2021
Change is fine with me, though I wish we understood why it's needed.
May 5 2021
compiler-rt/test/fuzzer is better. Most tests there already build with ASan + libFuzzer.
May 4 2021
Thanks for the fix. Could you add a test that fails before this fix and passes after it?