Late fix for SVN r. 324034
Add new interceptors: strlcpy(3) and strlcat(3)
There was forgotten an addition of len to the return value.
llvm-svn: 324091
Summary:
Implement `MonotonicNanoTime` using `QueryPerformanceCounter`.
This function is used by Scudo & the 64-bit Primary allocator. Implementing it
now means that the release-to-OS mechanism of the Primary will kick in (it
never did since the function returned 0 always), but `ReleaseMemoryPagesToOS` is
still not currently implemented for Windows.
Performance wise, this adds a syscall & a 64-bit division per call to
`MonotonicNanoTime` so the impact might not be negligible, but I don't think
there is a way around it.
Reviewers: rnk, alekseyshl, amccarth
Reviewed By: alekseyshl, amccarth
Subscribers: amccarth, flowerhack, kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42579
llvm-svn: 324011
Summary:
Few changes to the secondary:
- mark `const` variables as such;
- change some `CHECK` to `DCHECK`: I don't feel we need to be as conservative as
we were with out checks, as they are the results of our own computation.
- mark a condition as `UNLIKELY`.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42696
llvm-svn: 323997
Summary:
With the change, one can choose not to report comparison (or subtraction)
of a pointer with nullptr pointer.
Reviewers: kcc, jakubjelinek, alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D41479
llvm-svn: 323995
This avoids the warnings when building with LLVM_ENABLE_LIBCXX
which automatically adds -stdlib=libc++ to CMAKE_CXX_FLAGS.
Differential Revision: https://reviews.llvm.org/D42238
llvm-svn: 323969
Summary:
This change expands the amount of registers stashed by the entry and
`__xray_CustomEvent` trampolines.
We've found that since the `__xray_CustomEvent` trampoline calls can show up in
situations where the scratch registers are being used, and since we don't
typically want to affect the code-gen around the disabled
`__xray_customevent(...)` intrinsic calls, that we need to save and restore the
state of even the scratch registers in the handling of these custom events.
Reviewers: pcc, pelikan, dblaikie, eizan, kpw, echristo, chandlerc
Reviewed By: echristo
Subscribers: chandlerc, echristo, hiraditya, davide, dblaikie, llvm-commits
Differential Revision: https://reviews.llvm.org/D40894
llvm-svn: 323940
This change updates the Fuchsia-specific code to use the C++ friendly
duration expressions and flips on the building of
libclang_rt.fuzzer-x86_64.a and similar for Fuchsia. Given that
compiler-rt doesn't build on Fuchsia, test have been run by explicitly
building the library and linking it against
lib/fuzzer/tests/FuzzerUnittest.cpp.
Differential Revision: https://reviews.llvm.org/D42670
llvm-svn: 323828
Summary:
This is in preparation for platforms where `SANITIZER_SUPPORTS_WEAK_HOOKS` is 0.
They require a default implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42557
llvm-svn: 323795
Summary:
This is a follow-up to D42506.
There are a few of things that bothered me about `scudo_interceptors.cpp`:
- the filename is a misnomer: it intercepts some functions, but the rest (C++)
is actually in `scudo_new_delete.cpp`. I feel like `scudo_malloc.cpp` is more
appropriate (ASan uses the same naming scheme);
- we do not need "full" interceptors, since we are never accessing the
unsanitized version of the functions, we just need the
`extern "C" INTERCEPTOR_ATTRIBUTE` part of it to just call our functions;
- a couple of functions where duplicated while they could just be `ALIAS`'d;
- use the `SANITIZER_INTERCEPT_*` defines to hide the unneeded interceptors;
- use `SIZE_T` instead of `uptr`: while it's the same behind the curtain,
the former is meant for this use case.
In the end there is no functional change on the currently supported platforms
(Linux, Android).
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, hintonda, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42546
llvm-svn: 323464
Summary:
Implement `GetNumberOfCPUs` using `GetNativeSystemInfo`.
The only consummer of this function is Scudo which is not functional on
Windows yet.
Reviewers: rnk, zturner
Reviewed By: zturner
Subscribers: zturner, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42547
llvm-svn: 323462
Summary:
Currently all platforms are using the `scudo_interceptors.cpp` interceptors.
We might to come up with platform specific interceptors when/if we get Apple &
Windows, but as of now, that allows for Fuchsia to use them.
`scudo_new_delete.cpp` didn't have the `#if SANITIZER_LINUX` so it's good to go.
Reviewers: alekseyshl, flowerhack
Reviewed By: flowerhack
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42506
llvm-svn: 323386
Summary:
Hooks in the allocation & deallocation paths can be a security risk (see for an
example https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-advancing-exploitation.html
which used the glibc's __free_hook to complete exploitation).
But some users have expressed a need for them, even if only for tests and
memory benchmarks. So allow for `__sanitizer_malloc_hook` &
`__sanitizer_free_hook` to be called if defined, and gate them behind a global
define `SCUDO_CAN_USE_HOOKS` defaulting to 0.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42430
llvm-svn: 323278
Summary:
Now that ubsan does function interception (for signals), we
need to ensure that ubsan is initialized before any library
constructors are called. Otherwise, if a constructor calls
sigaction, ubsan will intercept in an unitialized state, which
will cause a crash.
This patch is a partial revert of r317757, which removed
preinit arrays for ubsan.
Reviewers: vitalybuka, eugenis, pcc
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42389
llvm-svn: 323249
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323054
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323032
MemToShadowImpl() maps lower addresses to a memory space out of sanitizers
range. The simplest example is address 0 which is mapped to 0x2000000000
static const uptr kShadowBeg = 0x2400000000ull;
but accessing the address during tsan execution will lead to a segmentation
fault.
This patch expands the range used by the sanitizer and ensures that 1/8 of
the maximum valid address in the virtual address spaces is used for shadow
memory.
Patch by Milos Stojanovic.
Differential Revision: https://reviews.llvm.org/D41777
llvm-svn: 323013
Summary:
We somehow never did it, and it raised no issue until now, when trying to
enable Fuchsia as a supported Scudo platform in the cmake config.
So propagate SANITIZER_COMMON_LINK_FLAGS for now.
Reviewers: alekseyshl, flowerhack
Reviewed By: flowerhack
Subscribers: mgorny, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42314
llvm-svn: 322999
Summary:
While there, unify InMemoryRawLog and InMemoryRawLogWithArg's coding style:
- swap libc's memcpy(3) for sanitizer's internal memcpy
- use basic pointer arithmetics to compute offsets from the first record
entry in the pre-allocated buffer, which is always the appropriate type
for the given function
- lose the local variable references as the TLD.* names fit just as well
Reviewers: eizan, kpw, dberris, dblaikie
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42289
llvm-svn: 322941
Generalize this handling to a separate toplevel ifdef (since any
windows case should use the same function), instead of indenting
the aarch64 case one step further.
Differential Revision: https://reviews.llvm.org/D42197
llvm-svn: 322928
Summary:
Make common allocator agnostic to failure handling modes and move the
decision up to the particular sanitizer's allocator, where the context
is available (call stack, parameters, return nullptr/crash mode etc.)
It simplifies the common allocator and allows the particular sanitizer's
allocator to generate more specific and detailed error reports (which
will be implemented later).
The behavior is largely the same, except one case, the violation of the
common allocator's check for "size + alignment" overflow is now reportied
as OOM instead of "bad request". It feels like a worthy tradeoff and
"size + alignment" is huge in this case anyway (thus, can be interpreted
as not enough memory to satisfy the request). There's also a Report()
statement added there.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42198
llvm-svn: 322784
Summary:
A forgotten include in `scudo_allocator.cpp` made the symbol only local :/
Before:
```
nm ./lib/clang/7.0.0/lib/linux/libclang_rt.scudo-i686-android.so | grep rss
00024730 t __scudo_set_rss_limit
```
After:
```
nm ./lib/clang/7.0.0/lib/linux/libclang_rt.scudo-i686-android.so | grep rs
00024760 T __scudo_set_rss_limit
```
And we want `T`!
This include also means that we can get rid of the `extern "C"` in the C++
file, the compiler does fine without it (note that this was already the case
for all the `__sanitizer_*` interface functions.
Reviewers: alekseyshl, eugenis
Reviewed By: eugenis
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42199
llvm-svn: 322782
