It hasn't seen active development in years, and it hasn't reached a
state where it was useful.
Remove the code until someone is interested in working on it again.
Differential Revision: https://reviews.llvm.org/D59133
llvm-svn: 355862
Summary:
Refactor the way /proc/self/maps entries are annotated to support most
(all?) posix platforms, with a special implementation for Android.
Extend the set of decorated Mmap* calls.
Replace shm_open with internal_open("/dev/shm/%s"). Shm_open is
problematic because it calls libc open() which may be intercepted.
Generic implementation has limits (max number of files under /dev/shm is
64K on my machine), which can be conceivably reached when sanitizing
multiple programs at once. Android implemenation is essentially free, and
enabled by default.
The test in sanitizer_common is copied to hwasan and not reused directly
because hwasan fails way too many common tests at the moment.
Reviewers: pcc, vitalybuka
Subscribers: srhines, kubamracek, jfb, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D57720
llvm-svn: 353255
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary: If user wants to raise it back, let them.
Reviewers: kcc, vitalybuka
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D54190
llvm-svn: 346284
Summary:
The previous version of the patch makes some code unable to distinguish
failure to map address 0 and error.
Revert to turn the bots back to green while figuring out a new approach.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51451
llvm-svn: 340957
Summary:
`MmapNoAccess` & `MmapFixedNoAccess` return directly the result of
`internal_mmap`, as opposed to other Mmap functions that return nullptr.
This inconsistency leads to some confusion for the callers, as some check for
`~(uptr)0` (`MAP_FAILED`) for failure (while it can fail with `-ENOMEM` for
example).
Two potential solutions: change the callers, or make the functions return
`nullptr` on failure to follow the precedent set by the other functions.
The second option looked more appropriate to me.
Correct the callers that were wrongly checking for `~(uptr)0` or
`MAP_FAILED`.
TODO for follow up CLs:
- There are a couple of `internal_mmap` calls in XRay that check for
MMAP_FAILED as a result as well (cc: @dberris); they should use
`internal_iserror`;
Reviewers: eugenis, alekseyshl, dberris, kubamracek
Reviewed By: alekseyshl
Subscribers: kristina, kubamracek, delcypher, #sanitizers, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D50940
llvm-svn: 340576
MmapFixedNoReserve does not terminate process on failure.
Failure to check its result and die will always lead to harder
to debug crashes later in execution. This was observed in Go
processes due to some address space conflicts.
Consistently check result of MmapFixedNoReserve.
While we are here also add warn_unused_result attribute
to prevent such bugs in future and change return type to bool
as that's what all callers want.
Reviewed in https://reviews.llvm.org/D49367
llvm-svn: 337531
Currently in FreeBSD 12.0-CURRENT with trunk clang+compiler-rt, faulty -fsanitize=address executable hangs at 'urdlck' state.
Ka Ho Ng has verified that by backporting this to llvm 6.0.1, with use_madv_dontdump=1, shadow memory is not dumped.
ASAN_OPTIONS=abort_on_error=1:disable_coredump=0:use_madv_dontdump=1 ./a
Reviewers: dimitry, kcc, dvyukov, emaste, khng300
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48257
llvm-svn: 336046
Summary:
Move madvise(MADV_NOHUGEPAGE) for the meta shadow memory after the meta
shadow memory is mapped (currently it silently fails with ENOMEM).
Add a diagnostic message to detect similar problems in the future.
Reviewers: dvyukov
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D48097
llvm-svn: 334624
Summary:
Some of the functions had spurious conditional statements and checks, and some
intermediary variables that I feel made the code more complicated than it needs
to be. Also, when unmapping the whole range, the range size would be 0, but
the base was set to the address of the end of the range, which sounds prone to
error. I think nulling out the base in this scenario is a better way to go.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45775
llvm-svn: 330355
IsStackOverflow only treats accesses within 512 bytes of SP as stack-overflow. This should really be the size of a page instead.
The scariness_score_test.cc triggers stack overflow with frames that are even larger than a page, which can also trigger a fault that will not be recognized as stack-overflow. Let's just use smaller frames.
llvm-svn: 329980
Summary:
`Symbolizer::PrepareForSandboxing` is empty for all platforms and apparently
has been for a while (D10213). Remove it, and shuffle things around so that the
platform specific code is now in `PlatformPrepareForSandboxing`.
This allows to have one less symbolizer dependency in a common file, which
helps for the upcoming split.
Also remove `SymbolizerPrepareForSandboxing` in tsan_go which appears to not
be used anywhere.
Reviewers: alekseyshl, eugenis, dvyukov, mcgrathr
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44953
llvm-svn: 329094
This patch changes hwasan inline instrumentation:
Fixes address untagging for shadow address calculation (use 0xFF instead of 0x00 for the top byte).
Emits brk instruction instead of hlt for the kernel and user space.
Use 0x900 instead of 0x100 for brk immediate (0x100 - 0x800 are unavailable in the kernel).
Fixes and adds appropriate tests.
Patch by Andrey Konovalov.
Differential Revision: https://reviews.llvm.org/D43135
llvm-svn: 325711
Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.
This part was initially developed inside libsanitizer in the GCC tree and should apply to
both. Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.
I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.
Most of the changes are probably straightforward with a few exceptions:
* The Solaris syscall interface isn't stable, undocumented and can change within an
OS release. The stable interface is the libc interface, which I'm using here, if possible
using the internal _-prefixed names.
* While the patch primarily target 32-bit x86, I've left a few sparc changes in. They
cannot currently be used with clang due to a backend limitation, but have worked
fine inside the gcc tree.
* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.
The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some
still TBD:
AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations
Maybe this is good enough the get the ball rolling.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40898
llvm-svn: 320740
MADV_DONTNEED on Linux actually mark the pages as free to be overwritten with zeroes, but on Darwin and BSD, it's just an advisory flag (the OS cannot discard the content). We should use MADV_FREE on Darwin and BSD.
Differential Revision: https://reviews.llvm.org/D40666
llvm-svn: 320659
Summary:
Now that the sanitizer_common interface for MmapNoAccess / MmapFixed
have been refactored to allow a more OO-esque access pattern, update the
Fuchsia mmap implementation to take advantage of this.
Previously MmapNoAccess / MmapFixed relied on a global allocator_vmar,
since the sanitizer_allocator only called MmapNoAccess once. Now, we
create a new VMAR per ReservedAddressRange object.
This allows the sanitizer allocator to work in tandem with the Scudo
secondary allocator.
This is part 4 of a 4 part changeset:
* part 1 https://reviews.llvm.org/D38593
* part 2 https://reviews.llvm.org/D38592
* part 3 https://reviews.llvm.org/D38593
Reviewers: mcgrathr, cryptoad
Reviewed By: cryptoad
Subscribers: alekseyshl, mcgrathr, kubamracek, mehdi_amini
Differential Revision: https://reviews.llvm.org/D38595
llvm-svn: 319083
Summary:
The ScudoAllocator uses a SecondaryHeader to keep track of the size and base address of each mmap'd chunk.
This aligns well with what the ReservedAddressRange is trying to do. This changeset converts the scudo allocator from using the MmapNoAccess/MmapFixed APIs to the ReservedAddressRange::Init and ::Map APIs. In doing so, it replaces the SecondayHeader struct with the ReservedAddressRange object.
This is part 3 of a 4 part changeset; part 1 https://reviews.llvm.org/D39072 and part 2 https://reviews.llvm.org/D38592
Reviewers: alekseyshl, mcgrathr, cryptoad, phosek
Reviewed By: cryptoad
Subscribers: llvm-commits, cryptoad, kubamracek
Differential Revision: https://reviews.llvm.org/D38593
llvm-svn: 318080
Summary:
Update sanitizer_allocator to use new API.
Second patch in a series. First patch https://reviews.llvm.org/D39072
Updates MmapNoAccess / MmapFixed call sites in the saniziter_allocator
to use the new Init/Map APIs instead.
Reviewers: alekseyshl, cryptoad, phosek, mcgrathr, dvyukov
Reviewed By: alekseyshl, cryptoad
Subscribers: dvyukov, mcgrathr, kubamracek
Differential Revision: https://reviews.llvm.org/D38592
llvm-svn: 317586
Summary:
Fixed version of https://reviews.llvm.org/D38437 (fixes Win/Fuchsia failures).
Creating a new revision, since the old one was getting a bit old/crowded.
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Reviewers: alekseyshl, cryptoad, phosek
Reviewed By: alekseyshl, cryptoad
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D39072
llvm-svn: 316934
The SanitizerCommon.ReservedAddressRangeUnmap test fails on Windows:
FAIL: SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap (34003 of 35554)
******************** TEST 'SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap' FAILED ********************
Note: Google Test filter = SanitizerCommon.ReservedAddressRangeUnmap
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from SanitizerCommon
[ RUN ] SanitizerCommon.ReservedAddressRangeUnmap
==3780==ERROR: SanitizerTool failed to deallocate 0x1000 (4096) bytes at address 0x0000000c3000 (error code: 487)
==3780==Sanitizer CHECK failed: E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:129 (("unable to unmap" && 0)) != (0) (0, 0)
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 299.76s
********************
Failing Tests (1):
SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap
> In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
> VMAR, which means that MmapNoAccess can only be called once. This works
> for the sanitizer allocator but *not* for the Scudo allocator.
>
> Hence, this changeset introduces a new ReservedAddressRange object to
> serve as the new API for these calls. In this changeset, the object
> still calls into the old Mmap implementations.
>
> The next changeset two changesets will convert the sanitizer and scudo
> allocators to use the new APIs, respectively. (ReservedAddressRange will
> replace the SecondaryHeader in Scudo.)
>
> Finally, a last changeset will update the Fuchsia implementation.
>
> Patch by Julia Hansbrough
>
> Differential Revision: https://reviews.llvm.org/D38437
llvm-svn: 315553
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Patch by Julia Hansbrough
Differential Revision: https://reviews.llvm.org/D38437
llvm-svn: 315533
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Patch by Julia Hansbrough
Differential Revision: https://reviews.llvm.org/D38759
llvm-svn: 315493
Summary:
NetBSD is an Open-Source POSIX-like BSD Operating System.
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, kcc, vitalybuka, filcab, fjricci
Reviewed By: kcc
Subscribers: llvm-commits, kubamracek, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D37193
llvm-svn: 311933
Summary:
On Android we still need to reset preinstalled handlers and allow use handlers later.
This reverts commit r304039.
Reviewers: eugenis
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D34434
llvm-svn: 305871
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
Summary:
Lsan was using PTHREAD_CREATE_JOINABLE/PTHREAD_CREATE_DETACHED
as truthy values, which works on Linux, where the values are 0 and 1,
but this fails on OS X, where the values are 1 and 2.
Set PTHREAD_CREATE_DETACHED to the correct value for a given system.
Reviewers: kcc, glider, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31883
llvm-svn: 300221
Summary:
The current code was sometimes attempting to release huge chunks of
memory due to undesired RoundUp/RoundDown interaction when the requested
range is fully contained within one memory page.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27228
llvm-svn: 288271
Currently we either define SANITIZER_GO for Go or don't define it at all for C++.
This works fine with preprocessor (ifdef/ifndef/defined), but does not work
for C++ if statements (e.g. if (SANITIZER_GO) {...}). Also this is different
from majority of SANITIZER_FOO macros which are always defined to either 0 or 1.
Always define SANITIZER_GO to either 0 or 1.
This allows to use SANITIZER_GO in expressions and in flag default values.
Also remove kGoMode and kCppMode, which were meant to be used in expressions,
but they are not defined in sanitizer_common code, so SANITIZER_GO become prevalent.
Also convert some preprocessor checks to C++ if's or ternary expressions.
Majority of this change is done mechanically with:
sed "s#ifdef SANITIZER_GO#if SANITIZER_GO#g"
sed "s#ifndef SANITIZER_GO#if \!SANITIZER_GO#g"
sed "s#defined(SANITIZER_GO)#SANITIZER_GO#g"
llvm-svn: 285443
Reset the SIGABRT signal handler before calling abort().
Also, change the error message when catching SIGABRT to say "ABRT"
instead of "SEGV".
llvm-svn: 280885
Summary:
Adds detection of large stack size rlimits (over 1 TB or unlimited), which
results in an mmap location that our shadow mapping does not support. We
re-exec the application in this situation. Adds a test of this behavior.
Adds general detection of mmap regions outside of our app regions. In the
future we want to try to adaptively handle these but for now we abort.
Moves the existing Linux-specific mmap code into a platform-specific file
where the new rlimit code lives.
Reviewers: eugenis
Subscribers: vitalybuka, zhaoqin, kcc, aizatsky, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D20745
llvm-svn: 271079
This reverts commit r267094, because it broke a lot of MSAN tests in AArch64.
Being NFC and all, this needs some deeper investigation before it goes in again.
llvm-svn: 267136
Nico Weber