Each function's PC is recorded in the ring buffer. From there we can access
the function's local variables and reconstruct the tag of each one with the
help of the information printed by llvm-symbolizer's new FRAME command. We
can then find the variable that was likely being accessed by matching the
pointer's tag against the reconstructed tag.
Differential Revision: https://reviews.llvm.org/D63469
llvm-svn: 364607
These lit configuration files are really Python source code. Using the
.py file extension helps editors and tools use the correct language
mode. LLVM and Clang already use this convention for lit configuration,
this change simply applies it to all of compiler-rt.
Reviewers: vitalybuka, dberris
Differential Revision: https://reviews.llvm.org/D63658
llvm-svn: 364591
While checking warnings from the Solaris buildbots, I noticed
llvm-lit: /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/test/asan/lit.cfg:119: warning: %shared_libasan substitution not set but dynamic ASan is available.
Fixed as follows. Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D63761
llvm-svn: 364394
Summary:
Previously we were running these tests without the "shadow-memory"
lit parallelism group even though we run the ASan and TSan tests in
this group to avoid problems with many processes using shadow memory
in parallel.
On my local machine the UBSan+TSan tests would previously timeout
if I set a 30 second per test limit. With this change I no longer
see individual test timeouts.
This change was made in response to the greendragon build bot reporting
individual test timeouts for these tests. Given that the UBSan+ASan and
UBSan+TSan tests did not have a parallelism group previously it's likely
that some other change has caused the performance degradation. However
I haven't been able to track down the cause so until we do, this change
seems reasonable and is in line with what we already do with ASan and
TSan tests.
rdar://problem/51754620
Reviewers: yln, kubamracek, vsk, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63797
llvm-svn: 364366
Summary:
User code can open a file on its own and pass it to the runtime, rather than
specifying a name and having the runtime open the file. This supports the use
case where a process cannot open a file on its own but can receive a file
descriptor from another process.
Relanding https://reviews.llvm.org/D62541. The original revision unlocked
the file before calling flush, this revision fixes that.
Reviewers: Dor1s, davidxl
Reviewed By: Dor1s
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63581
llvm-svn: 364231
These days, Python 3 installs itself into Program Files, so it often has
spaces. At first, I resisted this, and I reinstalled it globally into
C:/Python37, similar to the location used for Python 2.7. But then I
updated VS 2019, and it uninstalled my copy of Python and installed a
new one inside "C:/Program Files (x86)/Microsoft Visual Studio/". At
this point, I gave up and switched to using its built-in version of
Python. However, now these tests fail, and have to be made aware of the
possibility of spaces in paths. :(
llvm-svn: 364077
This caused Chromium's clang package to stop building, see comment on
https://reviews.llvm.org/D61242 for details.
> Summary:
> The main problem here is that `-*-version_min=` was not being passed to
> the compiler when building test cases. This can cause problems when
> testing on devices running older OSs because Clang would previously
> assume the minimum deployment target is the the latest OS in the SDK
> which could be much newer than what the device is running.
>
> Previously the generated value looked like this:
>
> `-arch arm64 -isysroot
> <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
>
> With this change it now looks like:
>
> `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot
> <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
>
> This mirrors the setting of `config.target_cflags` on macOS.
>
> This change is made for ASan, LibFuzzer, TSan, and UBSan.
>
> To implement this a new `get_test_cflags_for_apple_platform()` function
> has been added that when given an Apple platform name and architecture
> returns a string containing the C compiler flags to use when building
> tests. This also calls a new helper function `is_valid_apple_platform()`
> that validates Apple platform names.
>
> This is the second attempt at landing the patch. The first attempt (r359305)
> had to be reverted (r359327) due to a buildbot failure. The problem was
> that calling `get_test_cflags_for_apple_platform()` can trigger a CMake
> error if the provided architecture is not supported by the current
> CMake configuration. Previously, this could be triggered by passing
> `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were
> generating test configurations for a list of architectures without
> checking if the relevant Sanitizer actually supported that architecture.
> We now intersect the list of architectures for an Apple platform
> with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer
> name) to iterate through the correct list of architectures.
>
> rdar://problem/50124489
>
> Reviewers: kubamracek, yln, vsk, juliehockett, phosek
>
> Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits
>
> Tags: #llvm, #sanitizers
>
> Differential Revision: https://reviews.llvm.org/D61242
llvm-svn: 363779
These tests won't necessarily work because the reported modules paths
from the device don't match what's on the host and so offline
symbolization fails.
llvm-svn: 363641
Split `Darwin/asan-symbolize-partial-report-with-module-map.cc` into two
separate test cases due to them testing slightly different things.
llvm-svn: 363640
Summary:
The use case here is to be able symbolicate ASan reports that might be
partially symbolicated, in particular where the function name is known but no source
location is available. This can be caused by missing debug info. Previously we
would only try to symbolicate completely unsymbolicated reports.
The code currently contains an unfortunate quirk to handle a darwin
specific bug (rdar://problem/49784442) in the way partially symbolicated
reports are emitted when the source location is missing.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: aprantl, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60533
llvm-svn: 363639
This saves roughly 32 bytes of instructions per function with stack objects
and causes us to preserve enough information that we can recover the original
tags of all stack variables.
Now that stack tags are deterministic, we no longer need to pass
-hwasan-generate-tags-with-calls during check-hwasan. This also means that
the new stack tag generation mechanism is exercised by check-hwasan.
Differential Revision: https://reviews.llvm.org/D63360
llvm-svn: 363636
Summary:
The main problem here is that `-*-version_min=` was not being passed to
the compiler when building test cases. This can cause problems when
testing on devices running older OSs because Clang would previously
assume the minimum deployment target is the the latest OS in the SDK
which could be much newer than what the device is running.
Previously the generated value looked like this:
`-arch arm64 -isysroot
<path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
With this change it now looks like:
`-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot
<path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
This mirrors the setting of `config.target_cflags` on macOS.
This change is made for ASan, LibFuzzer, TSan, and UBSan.
To implement this a new `get_test_cflags_for_apple_platform()` function
has been added that when given an Apple platform name and architecture
returns a string containing the C compiler flags to use when building
tests. This also calls a new helper function `is_valid_apple_platform()`
that validates Apple platform names.
This is the second attempt at landing the patch. The first attempt (r359305)
had to be reverted (r359327) due to a buildbot failure. The problem was
that calling `get_test_cflags_for_apple_platform()` can trigger a CMake
error if the provided architecture is not supported by the current
CMake configuration. Previously, this could be triggered by passing
`-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were
generating test configurations for a list of architectures without
checking if the relevant Sanitizer actually supported that architecture.
We now intersect the list of architectures for an Apple platform
with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer
name) to iterate through the correct list of architectures.
rdar://problem/50124489
Reviewers: kubamracek, yln, vsk, juliehockett, phosek
Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61242
llvm-svn: 363633
Summary:
See D60593 for further information.
This patch adds GWP-ASan support to the Scudo hardened allocator. It also
implements end-to-end integration tests using Scudo as the backing allocator.
The tests include crash handling for buffer over/underflow as well as
use-after-free detection.
Reviewers: vlad.tsyrklevich, cryptoad
Reviewed By: vlad.tsyrklevich, cryptoad
Subscribers: kubamracek, mgorny, #sanitizers, llvm-commits, morehouse
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D62929
llvm-svn: 363584
Summary:
Some custom mutators may not peform well when size restriction is
enforced by len_control. Because of that, it's safer to disable len_control
by default in such cases, but still allow users to enable it manually.
Bug example: https://bugs.chromium.org/p/chromium/issues/detail?id=919530.
Tested manually with LPM-based and regular fuzz targets.
Reviewers: kcc, vitalybuka, metzman
Reviewed By: kcc, metzman
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D63334
llvm-svn: 363443
It broke the Windows build:
C:\b\s\w\ir\cache\builder\src\third_party\llvm\compiler-rt\lib\fuzzer\FuzzerDataFlowTrace.cpp(243): error C3861: 'setenv': identifier not found
This also reverts the follow-up r363327.
llvm-svn: 363358
Summary:
dfsan_flush() allows to restart tain tracking from scratch in the same process.
The primary purpose right now is to allow more efficient data flow tracing
for DFT fuzzing: https://github.com/google/oss-fuzz/issues/1632
Reviewers: pcc
Reviewed By: pcc
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D63037
llvm-svn: 363321
This patch aims to fix the test case, name_to_handle_at.cc that fails on Docker.
Overlay2 on Docker does not support the current check for the name_to_handle_at()
function call of the test case. The proposed fix is to check for /dev/null in
the test instead, as this check is supported. Checking for /dev/null has been
utilized in the past for other test cases, as well.
Differential Revision: https://reviews.llvm.org/D63094
llvm-svn: 363167
This caused instrumented Clang to become crashy. See llvm-commits thread
for repro steps.
This also reverts follow-up r362716 which added test cases.
> Author: Sajjad Mirza
>
> Differential Revision: http://reviews.llvm.org/D62541
llvm-svn: 363134
Summary:
This class is useful for writing fuzz target that have multiple inputs.
Current CL imports the existing `FuzzedDataProvider` from Chromium
without any modifications. Feel free to review it thoroughly, if you're
interested, but I'd prefer changing the class in a follow up CL.
The CL also introduces an exhaustive test for the library, as the behavior
of `FuzzedDataProvider` must not change over time.
In follow up CLs I'm planning on changing some implementation details
(I can share a doc with some comments to be addressed). After that, we
will document how `FuzzedDataProvider` should be used.
I have tested this on Linux, Windows and Mac platforms.
Reviewers: morehouse, metzman, kcc
Reviewed By: morehouse
Subscribers: metzman, thakis, rnk, mgorny, ormris, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D62733
llvm-svn: 363071
Summary:
Longstanding issues in the Android test runner means that compiler-rt unit
tests don't work on Android due to libc++ link-time issues. Looks like the
exported libc++ from the Android NDK is x86-64, even though it's part of the
ARM[64] toolchain... See similar measures for ASan and sanitizer-common that
disable unit tests for Android.
Should fully fix the Android bots (@vlad.tsyrklevich).
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, kubamracek, mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits, vlad.tsyrklevich
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63019
llvm-svn: 362842
to try and fix android buildbot. Also make sure that the empty dummy
test contains an output file name so the android_build.py wrapper script
doesn't check fail.
llvm-svn: 362758
This allows instrumenting programs which have their own
versions of new and delete operators.
Differential revision: https://reviews.llvm.org/D62794
llvm-svn: 362478
Summary:
See D60593 for further information.
This patch pulls out the mutex implementation and the required definitions file.
We implement our own mutex for GWP-ASan currently, because:
1. We must be compatible with the sum of the most restrictive elements of the supporting allocator's build system. Current targets for GWP-ASan include Scudo (on Linux and Fuchsia), and bionic (on Android).
2. Scudo specifies `-nostdlib++ -nonodefaultlibs`, meaning we can't use `std::mutex` or `mtx_t`.
3. We can't use `sanitizer_common`'s mutex, as the supporting allocators cannot afford the extra maintenance (Android, Fuchsia) and code size (Fuchsia) overheads that this would incur.
In future, we would like to implement a shared base mutex for GWP-ASan, Scudo and sanitizer_common. This will likely happen when both GWP-ASan and Scudo standalone are not in the development phase, at which point they will have stable requirements.
Reviewers: vlad.tsyrklevich, morehouse, jfb
Reviewed By: morehouse
Subscribers: dexonsmith, srhines, cfe-commits, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, vitalybuka, eugenis
Tags: #sanitizers, #llvm, #clang
Differential Revision: https://reviews.llvm.org/D61923
llvm-svn: 362138
In particular, don't call get_target_flags_for_arch() since that
will cause an error in some situations:
If DARWIN_iossim_ARCHS=i386;x86_64, DARWIN_osx_ARCHS=x86_64, and
DARWIN_iossym_SYSROOT isn't set (due to the simulator sysroot not being
available), then config-ix.cmake won't add i386 to COMPILER_RT_SUPPORTED_ARCH
but ubsan's test/CMakeLists.txt would call get_target_flags_for_arch()
with i386, which would then run into the error in
get_target_flags_for_arch().
Having these conditions isn't ideal. The background here is that we
configure our mac-hosted trunk bots all the same (so they all have the
same DARWIN_*_archs, and we don't easily know if a mac host bot is
targeting mac or ios at the place where we call cmake), but only the
ios-targeting bots have ios sysroots available.
This will hopefully unbreak that use case without impacting anything
else -- and it makes ubsan and asan test setup more alike.
llvm-svn: 362010
ShallowOOMDeepCrash.cpp may hit libFuzzer's RSS limit before the SIGUSR2
is delivered, causing the test to be flaky when bots are under load.
SleepOneSecondTest.cpp will keep running until the signal is delivered.
llvm-svn: 361048
Summary:
Adds a call to __hwasan_handle_vfork(SP) at each landingpad entry.
Reusing __hwasan_handle_vfork instead of introducing a new runtime call
in order to be ABI-compatible with old runtime library.
Reviewers: pcc
Subscribers: kubamracek, hiraditya, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61968
llvm-svn: 360959
Peter Collingbourne