| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
and disabling it forAndroid.
Reviewers: krytarowski, vitalybuka
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D66027
llvm-svn: 368504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that malloc_default_zone and malloc_zone_from_ptr return the
sanitizer-installed malloc zone even when MallocStackLogging (MSL) is
requested. This prevents crashes in certain situations. Note that the
sanitizers and MSL cannot be used together. If both are enabled, MSL
functionality is essentially deactivated since it only hooks the default
allocator which is replaced by a custom sanitizer allocator.
rdar://53686175
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D65990
llvm-svn: 368492
|
|
|
|
|
|
|
|
| |
that tried to fix the build as it's still broken.
This reverts commit 368476 and 368480.
llvm-svn: 368481
|
|
|
|
|
|
|
|
|
| |
That revision broke compilation with this error:
lib/builtins/fixunsxfdi.c:13:2: error: unterminated conditional directive
#if !_ARCH_PPC
llvm-svn: 368480
|
|
|
|
|
|
| |
- https://reviews.llvm.org/D66023
llvm-svn: 368476
|
|
|
|
|
|
|
|
|
| |
This reverts commit 52a36fae2a3f8560a5be690a67304db5edafc3fe.
This commit broke the sanitizer_android buildbot. See comments at
https://reviews.llvm.org/rL368373 for more details.
llvm-svn: 368472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The purpose is to be able to extract the number of new edges added to
the original (i.e. output) corpus directory after doing the merge. Use case
example: in ClusterFuzz, we do merge after every fuzzing session, to avoid
uploading too many corpus files, and we also record coverage stats at that
point. Having a separate line indicating stats after reading the initial output
corpus directory would make the stats extraction easier for both humans and
parsing scripts.
Context: https://github.com/google/clusterfuzz/issues/802.
Reviewers: morehouse, hctim
Reviewed By: hctim
Subscribers: delcypher, #sanitizers, llvm-commits, kcc
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D66020
llvm-svn: 368461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: Dor1s
Reviewed By: Dor1s
Subscribers: dberris, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D66017
llvm-svn: 368448
|
|
|
|
| |
llvm-svn: 368440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This bug occurred when a plug-in requested that a binary not be
symbolized while the script is trying to symbolize a stack frame. In
this case `self.frame_no` would not be incremented. This would cause
subsequent stack frames that are symbolized to be incorrectly numbered.
To fix this `get_symbolized_lines()` has been modified to take an
argument that indicates whether the stack frame counter should
incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)`
is now used in in the case where we don't want to symbolize a line so
that we can keep the frame counter increment in a single function.
A test case is included. The test uses a dummy plugin that always asks
`asan_symbolize.py` script to not symbolize the first binary that the
script asks about. Prior to the patch this would cause the output to
script to look something like
```
#0 0x0
#0 0x0 in do_access
#1 0x0 in main
```
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65495
llvm-svn: 368373
|
|
|
|
|
|
|
|
|
|
| |
See D65364 for the code model requirements for tagged globals. Because
of the relocations used these requirements cannot be checked at link
time so they must be checked at runtime.
Differential Revision: https://reviews.llvm.org/D65968
llvm-svn: 368351
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also slightly cleaned up the comments and changed the header's extension
back to `.h` as per comments on https://reviews.llvm.org/D65812.
New methods added:
* `ConsumeProbability` returns [0.0, 1.0] by consuming an unsigned integer value
from the input data and dividing that value by the integer's max value.
* `ConsumeFloatingPointInRange` returns a floating point value in the given
range. Relies on `ConsumeProbability` method. This method does not have the
limitation of `std::uniform_real_distribution` that requires the given range
to be <= the floating point type's max. If the range is too large, this
implementation will additionally call `ConsumeBool` to decide whether the
result will be in the first or the second half of the range.
* `ConsumeFloatingPoint` returns a floating point value in the range
`[std::numeric_limits<T>::lowest(), std::numeric_limits<T>::min()]`.
Tested on Linux, Mac, Windows.
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: kubamracek, mgorny, dberris, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65905
llvm-svn: 368331
|
|
|
|
|
|
|
|
| |
Register 36 new ioctl(2) calls.
Enable NVMM for amd64 as the API has been stabilized.
llvm-svn: 368247
|
|
|
|
|
|
| |
Register new ioctl argument types passed in ioctl(2) calls.
llvm-svn: 368246
|
|
|
|
| |
llvm-svn: 368242
|
|
|
|
|
|
|
|
|
|
| |
The fallback to the alternative implementation of TSD with TLS
is only needed for the static version of ASan for NetBSD.
The same code cannot be reused for the dynamic version of ASan as
TLS breaks and TSD code works.
llvm-svn: 368219
|
|
|
|
|
|
|
|
| |
HWASan+globals build fix in rL368111 unfortunately didn't fix the
problem when clang_cflags specified -fuse-ld=ld.gold. Change the order
to force lld in an attempt to fix the Android sanitizer bot.
llvm-svn: 368218
|
|
|
|
|
|
|
|
| |
We're using relocations that are unsupported by the version of gold on the
bot, so force the use of lld. One of the tests is already using lld,
so this should be safe.
llvm-svn: 368111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It appears that since https://reviews.llvm.org/D54889, BackgroundThread()
crashes immediately because cur_thread()-> will return a null pointer
which is then dereferenced. I'm not sure why I only see this issue on
FreeBSD and not Linux since it should also be unintialized on other platforms.
Reviewers: yuri, dvyukov, dim, emaste
Subscribers: kubamracek, krytarowski, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65705
llvm-svn: 368103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Globals are instrumented by adding a pointer tag to their symbol values
and emitting metadata into a special section that allows the runtime to tag
their memory when the library is loaded.
Due to order of initialization issues explained in more detail in the comments,
shadow initialization cannot happen during regular global initialization.
Instead, the location of the global section is marked using an ELF note,
and we require libc support for calling a function provided by the HWASAN
runtime when libraries are loaded and unloaded.
Based on ideas discussed with @evgeny777 in D56672.
Differential Revision: https://reviews.llvm.org/D65770
llvm-svn: 368102
|
|
|
|
| |
llvm-svn: 368093
|
|
|
|
|
|
|
|
|
|
|
|
| |
in madvise mode, the shadow pages will be migrated only via madvise explicit calls.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D65775
llvm-svn: 368090
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
.hpp makes more sense for this header as it's C++ only, plus it
contains the actual implementation.
Reviewers: Dor1s
Reviewed By: Dor1s
Subscribers: kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65812
llvm-svn: 368054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Straightforward implementation of `getrandom` syscall and libc
hooks.
Test Plan: Local MSAN failures caused by uninstrumented `getrandom`
calls stop failing.
Patch by Andrew Krieger.
Reviewers: eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, kubamracek, dberris, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D65551
llvm-svn: 367999
|
|
|
|
| |
llvm-svn: 367990
|
|
|
|
|
|
|
|
|
|
|
| |
Third landing attempt: Added "if (HAVE_LIBCXX)" to keep Green Dragon green.
Haven't found a better way to pass the libcxx include path for building
compiler-rt with libcxx; this seems to be missing only for xray.
Differential Revision: https://reviews.llvm.org/D65307
llvm-svn: 367962
|
|
|
|
|
|
|
|
|
|
| |
r356153 changed default build option of static libcxx to no PIC. We now
need to explicitly specify CMAKE_POSITION_INDEPENDENT_CODE to get PIC
libcxx.
Differential Revision: https://reviews.llvm.org/D65773
llvm-svn: 367943
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once we start instrumenting globals, all addresses including those of string literals
that we pass to the operating system will start being tagged. Since we can't rely
on the operating system to be able to cope with these addresses, we need to untag
them before passing them to the operating system. This change introduces a macro
that does so and uses it everywhere it is needed.
Differential Revision: https://reviews.llvm.org/D65768
llvm-svn: 367938
|
|
|
|
|
|
|
|
|
| |
See Intel SDM, Vol 2A, Table 3-8:
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2a-manual.pdf#page=296
Differential Revision: https://reviews.llvm.org/D65766
llvm-svn: 367929
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disabling Transparent huge page mode refactored in one function.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D65771
llvm-svn: 367925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
FuzzedDataProvider is a helper class for writing fuzz targets that fuzz
multple inputs simultaneously. The header is supposed to be used for fuzzing
engine agnostic fuzz targets (i.e. the same target can be used with libFuzzer,
AFL, honggfuzz, and other engines). The common thing though is that fuzz targets
are typically compiled with clang, as it provides all sanitizers as well as
different coverage instrumentation modes. Therefore, making this FDP class a
part of the compiler-rt installation package would make it easier to develop
and distribute fuzz targets across different projects, build systems, etc.
Some context also available in https://github.com/google/oss-fuzz/pull/2547.
This CL does not delete the header from `lib/fuzzer/utils` directory in order to
provide the downstream users some time for a smooth migration to the new
header location.
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: lebedev.ri, kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65661
llvm-svn: 367917
|
|
|
|
|
|
| |
All cc files have been renamed to cpp now.
llvm-svn: 367911
|
|
|
|
| |
llvm-svn: 367888
|
|
|
|
|
|
| |
See r367803 and similar other changes.
llvm-svn: 367887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See PR42868 for more details.
The affected list of tests is:
Failing Tests (8):
AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.LargeOOBRightTest
AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOBRightTest
AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOB_char
AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test.exe/AddressSanitizer.OOB_int
AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.LargeOOBRightTest
AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOBRightTest
AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOB_char
AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test.exe/AddressSanitizer.OOB_int
llvm-svn: 367874
|
|
|
|
|
|
|
|
|
| |
gtest's built-in regex engine doesn't support (). Looks like it's not
needed, just remove it.
See PR42868 for more details.
llvm-svn: 367873
|
|
|
|
|
|
| |
See r367803 and similar other changes.
llvm-svn: 367863
|
|
|
|
|
|
| |
See r367803 and similar other changes.
llvm-svn: 367858
|
|
|
|
| |
llvm-svn: 367856
|
|
|
|
|
|
| |
See r367803 and similar other changes.
llvm-svn: 367855
|
|
|
|
|
|
| |
See r367849 et al.
llvm-svn: 367854
|
|
|
|
|
|
| |
Should've been part of r367849.
llvm-svn: 367851
|
|
|
|
|
|
| |
Like r367463, but for test/hwasan.
llvm-svn: 367849
|
|
|
|
|
|
| |
Like r367463, but for test/lsan.
llvm-svn: 367803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
./Sanitizer-*-Test/SanitizerCommon.PthreadDestructorIterations on Solaris
SanitizerCommon.PthreadDestructorIterations currently FAILs on Solaris:
[ RUN ] SanitizerCommon.PthreadDestructorIterations
/vol/llvm/src/compiler-rt/local/lib/sanitizer_common/tests/sanitizer_posix_test.cc:58: Failure
Value of: destructor_executed
Actual: true
Expected: false
[ FAILED ] SanitizerCommon.PthreadDestructorIterations (1 ms)
It turns out that destructor is called 4 times after the first call to SpawnThread, but
5 times after the second. While PTHREAD_DESTRUCTOR_ITERATIONS is 4 in
<limits.h>, the Solaris pthread_key_create(3C) man page documents
If, after all the destructors have been called for all keys with non-
null values, there are still some keys with non-null values, the
process will be repeated. POSIX requires that this process be executed
at least PTHREAD_DESTRUCTOR_ITERATIONS times. Solaris calls the
destructors repeatedly until all values with associated destructors are
NULL. Destructors that set new values can cause an infinite loop.
The patch adjusts the test case to allow for this.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D65055
llvm-svn: 367705
|
|
|
|
|
|
| |
Like r367463, but for test/tsan.
llvm-svn: 367656
|
|
|
|
|
|
| |
Like r367463, but for test/msan.
llvm-svn: 367653
|
|
|
|
|
|
|
|
|
| |
Like r367463, but for test/xray.
Update test/xray/lit.cfg.py config.suffixes to remove .cc (we actually
don't have .c tests now)
llvm-svn: 367652
|
|
|
|
| |
llvm-svn: 367642
|
|
|
|
| |
llvm-svn: 367589
|