When set to non-zero, the HWASan runtime will map the shadow base at the
specified constant address.
This is particularly useful in conjunction with the existing compiler
option
'hwasan-mapping-offset', which bakes a hardcoded constant address into
the instrumentation.
---------
Co-authored-by: Thurston Dang <thurston@google.com>
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
This adds the sanitizer_common syscall hooks to HWASan and also defines
the COMMON_SYSCALL_PRE_{READ/WRITE}_RANGE macros.
Differential Revision: https://reviews.llvm.org/D149386
This is max acceptable value with pow of 2 for DefaultSizeClassMap, the
same as for ASAN.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D145536
Larger blocks are more convenient for compressions.
Blocks are allocated with MmapNoReserveOrDie to save some memory.
Also it's 15% faster on StackDepotBenchmarkSuite
Depends on D114464.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D114488
Before this change we were locking the StackDepot in the fork()
interceptor. This results in a deadlock when allocator functions are
used in a pthread_atfork() callback.
Instead, set up a pthread_atfork() callback at init that locks/unlocks
both StackDepot and the allocator. Since our callback is set up very
early, the pre-fork callback is executed late, and both post-fork ones
are executed early, which works perfect for us.
Differential Revision: https://reviews.llvm.org/D108063
-fsanitize-hwaddress-experimental-aliasing is intended to distinguish
aliasing mode from LAM mode on x86_64. check-hwasan is configured
to use aliasing mode while check-hwasan-lam is configured to use LAM
mode.
The current patch doesn't actually do anything differently in the two
modes. A subsequent patch will actually build the separate runtimes
and use them in each mode.
Currently LAM mode tests must be run in an emulator that
has LAM support. To ensure LAM mode isn't broken by future patches, I
will next set up a QEMU buildbot to run the HWASan tests in LAM.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D102288
This test has two modes - testing reused threads with multiple loops of
batch create/join, and testing new threads with a single loop of
create/join per fork.
The non-reuse variant catches the problem that was fixed in D101881 with
a high probability.
Differential Revision: https://reviews.llvm.org/D101936
Now that page aliasing for x64 has landed, we don't need to worry about
passing tagged pointers to libc, and thus D98875 removed it.
Unfortunately, we still test on aarch64 devices that don't have the
kernel tagged address ABI (https://reviews.llvm.org/D98875#2649269).
All the memory that we pass to the kernel in these tests is from global
variables. Instead of having architecture-specific untagging mechanisms
for this memory, let's just not tag the globals.
Reviewed By: eugenis, morehouse
Differential Revision: https://reviews.llvm.org/D101121
Userspace page aliasing allows us to use middle pointer bits for tags
without untagging them before syscalls or accesses. This should enable
easier experimentation with HWASan on x86_64 platforms.
Currently stack, global, and secondary heap tagging are unsupported.
Only primary heap allocations get tagged.
Note that aliasing mode will not work properly in the presence of
fork(), since heap memory will be shared between the parent and child
processes. This mode is non-ideal; we expect Intel LAM to enable full
HWASan support on x86_64 in the future.
Reviewed By: vitalybuka, eugenis
Differential Revision: https://reviews.llvm.org/D98875
Userspace page aliasing allows us to use middle pointer bits for tags
without untagging them before syscalls or accesses. This should enable
easier experimentation with HWASan on x86_64 platforms.
Currently stack, global, and secondary heap tagging are unsupported.
Only primary heap allocations get tagged.
Note that aliasing mode will not work properly in the presence of
fork(), since heap memory will be shared between the parent and child
processes. This mode is non-ideal; we expect Intel LAM to enable full
HWASan support on x86_64 in the future.
Reviewed By: vitalybuka, eugenis
Differential Revision: https://reviews.llvm.org/D98875
HwasanThreadList::DontNeedThread clobbers Thread::next_,
Breaking the freelist. As a result, only the top of the freelist ever
gets reused, and the rest of it is lost.
Since the Thread object with its associated ring buffer is only 8Kb, this is
typically only noticable in long running processes, such as fuzzers.
Fix the problem by switching from an intrusive linked list to a vector.
Differential Revision: https://reviews.llvm.org/D91392
HwasanThreadList::DontNeedThread clobbers Thread::next_, breaking the
freelist. As a result, only the top of the freelist ever gets reused,
and the rest of it is lost.
Since the Thread object its associated ring buffer is only 8Kb, this is
typically only noticable in long running processes, such as fuzzers.
Fix the problem by switching from an intrusive linked list to a vector.
Differential Revision: https://reviews.llvm.org/D91208
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
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
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
Summary:
Whenever a large shadow region is tagged to zero, madvise(DONT_NEED)
as much of it as possible.
This reduces shadow RSS on Android by 45% or so, and total memory use
by 2-4%, probably even more on long running multithreaded programs.
CPU time seems to be in the noise.
Reviewers: kcc, pcc
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D56757
llvm-svn: 351620
Summary:
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, not stack, no details, not too
helpful nor informative. To improve the situation, detailed and
structured errors were defined and reported under the appropriate conditions.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D47798
llvm-svn: 334248
