Summary:
The Combined allocator hold together all the other components, and
provides a memory allocator interface based on various template
parameters. This will be in turn used by "wrappers" that will provide
the standard C and C++ memory allocation functions, but can be
used as is as well.
This doesn't depart significantly from the current Scudo implementation
except for a few details:
- Quarantine batches are now protected by a header a well;
- an Allocator instance has its own TSD registry, as opposed to a
static one for everybody;
- a function to iterate over busy chunks has been added, for Android
purposes;
This also adds the associated tests, and a few default configurations
for several platforms, that will likely be further tuned later on.
Reviewers: morehouse, hctim, eugenis, vitalybuka
Reviewed By: morehouse
Subscribers: srhines, mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D63231
llvm-svn: 363569
The default nm executable may not be able to handle the architecture
we're building the sanitizers for. Respect CMAKE_NM if it's set to
ensure we're using the correct nm tool. Preserve the existing NM
environment variable override to not break its users.
Differential Revision: https://reviews.llvm.org/D63368
llvm-svn: 363483
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 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:
The more tests are added, the more we are limited by the size of the
address space on 32-bit. Implement `unmapTestOnly` all around (like it
is in sanitzer_common) to be able to free up some memory.
This is not intended to be a proper "destructor" for an allocator, but
allows us to not fail due to having no memory left.
Reviewers: morehouse, vitalybuka, eugenis, hctim
Reviewed By: morehouse
Subscribers: delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D63146
llvm-svn: 363095
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
These "dynamic_runtime_thunk" object files exist to create a weak alias
from 'foo' to 'foo_dll' for all weak sanitizer runtime symbols. The weak
aliases are implemented as /alternatename linker options in the
.drective section, so they are not actually in the symbol table. In
order to force the Visual C++ linker to load the object, even with
-wholearchive:, we have to provide at least one external symbol. Once we
do that, it will read the .drective sections and see the weak aliases.
Fixes PR42074
llvm-svn: 362970
Summary:
This CL adds the structures dealing with thread specific data for the
allocator. This includes the thread specific data structure itself and
two registries for said structures: an exclusive one, where each thread
will have its own TSD struct, and a shared one, where a pool of TSD
structs will be shared by all threads, with dynamic reassignment at
runtime based on contention.
This departs from the current Scudo implementation: we intend to make
the Registry a template parameter of the allocator (as opposed to a
single global entity), allowing various allocators to coexist with
different TSD registry models. As a result, TSD registry and Allocator
are tightly coupled.
This also corrects a couple of things in other files that I noticed
while adding this.
Reviewers: eugenis, vitalybuka, morehouse, hctim
Reviewed By: morehouse
Subscribers: srhines, mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D62258
llvm-svn: 362962
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
Summary:
See D60593 for further information.
This patch introduces the core of GWP-ASan, being the guarded pool allocator. This class contains the logic for creating and maintaining allocations in the guarded pool. Its public interface is to be utilised by supporting allocators in order to provide sampled guarded allocation behaviour.
This patch also contains basic functionality tests of the allocator as unittests. The error-catching behaviour will be tested in upcoming patches that use Scudo as an implementing allocator.
Reviewers: vlad.tsyrklevich, eugenis, jfb
Reviewed By: vlad.tsyrklevich
Subscribers: dexonsmith, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, morehouse
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D62872
llvm-svn: 362636
Summary:
See D60593 for further information.
This patch introduces the configuration options for GWP-ASan. In general, we expect the supporting allocator to populate the options struct, and give that to GWP-ASan during initialisation. For allocators that are okay with pulling in sanitizer_common, we also provide an optional parser that populates the gwp_asan::Options struct with values provided in the GWP_ASAN_OPTIONS environment variable.
This patch contains very little logic, and all of the testable components (i.e. the optional parser's internal logic) is tested as part of the sanitizer_common testbed.
Reviewers: vlad.tsyrklevich, morehouse, jfb
Reviewed By: morehouse
Subscribers: dexonsmith, kubamracek, mgorny, #sanitizers, llvm-commits, vitalybuka
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D62698
llvm-svn: 362527
This allows instrumenting programs which have their own
versions of new and delete operators.
Differential revision: https://reviews.llvm.org/D62794
llvm-svn: 362478
compiler-rt already uses libtool instead of ar when building for
Apple platform, but that's not being used when builtins are being
built separately e.g. as part of the runtimes build. This change
extracts the logic setting up libtool into a separate file and uses
it from both the compiler-rt and standalone builtins build.
Differential Revision: https://reviews.llvm.org/D62820
llvm-svn: 362466
If `COMPILER_RT_ARMHF_TARGET` is set , the definition of the AEABI runtime
function `__aeabi_fcmpun` is misspelt: `__aeabi_fcmpum` instead of
`__aeabi_fcmpun`.
Patch by Konstantin Schwarz!
llvm-svn: 362424
Looks like armv8 can't handle a thousand threads, which GWP-ASan
requests when running a synchronised mutex test. Limiting this to 100 to
attempt to fix the build issue.
llvm-svn: 362163
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
This should hopefully address the error we're seeing in older versions
of Clang.
Differential Revision: https://reviews.llvm.org/D62554
llvm-svn: 361909
Fuchsia has several exceptions which are merely informational and should
not be treated as crashes. This patch puts logic that read from the
exception port and handled the exception in a loop, and ignores
non-exceptions and informational exceptions.
Patch By: aarongreen
Differential Revision: https://reviews.llvm.org/D62226
llvm-svn: 361407
The only difference between __eqsf2 and __gtsf2 is whether they return
1 or -1 on NaN. Rather than duplicating all the code, use a macro to
define the function twice and use an argument to decide whether to
negate the return value.
Differential Revision: https://reviews.llvm.org/D61919
llvm-svn: 361207
Summary:
This CL introduces the 32 & 64-bit primary allocators, and associated
Local Cache. While the general idea is mostly similar to what exists
in sanitizer_common, it departs from the original code somewhat
significantly:
- the 64-bit primary no longer uses a free array at the end of a region
but uses batches of free blocks in region 0, allowing for a
convergence with the 32-bit primary behavior;
- as a result, there is only one (templated) local cache type for both
primary allocators, and memory reclaiming can be implemented similarly
for the 32-bit & 64-bit platforms;
- 64-bit primary regions are handled a bit differently: we do not
reserve 4TB of memory that we split, but reserve `NumClasses *
2^RegionSizeLog`, each region being offseted by a random number of
pages from its computed base. A side effect of this is that the 64-bit
primary works on 32-bit platform (I don't think we want to encourage
it but it's an interesting side effect);
Reviewers: vitalybuka, eugenis, morehouse, hctim
Reviewed By: morehouse
Subscribers: srhines, mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61745
llvm-svn: 361159
This is needed when using compiler wrappers such as ccache or distcc
and should address the failure on clang-x86_64-debian-fast bot.
Differential Revision: https://reviews.llvm.org/D62104
llvm-svn: 361111
Summary:
Removed dependency on c++ standard library. Some supporting allocators (namely Scudo on Fuchsia, and shortly, scudo standalone) has a hard requirement of no c++stdlib.
This patch updates the build system so that we don't have any c++ stdlib dependencies. It also will conveniently fix a racy build-order bug discrepency between GWP-ASan and libc++.
Reviewers: phosek, morehouse
Reviewed By: phosek, morehouse
Subscribers: kubamracek, mgorny, cryptoad, #sanitizers, llvm-commits, beanz, smeenai, vitalybuka
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D62048
llvm-svn: 360982
Summary:
See D60593 for further information.
This patch slices off the PRNG implementation and the initial build files for GWP-ASan.
Reviewers: vlad.tsyrklevich, morehouse, vitalybuka
Reviewed By: morehouse
Subscribers: srhines, kubamracek, mgorny, #sanitizers, llvm-commits, cryptoad, eugenis
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61867
llvm-svn: 360710
We're building with -std=c11 now (as opposed to -std=gnu11), so we can't
use GNU extensions and need to spell inline assembly as __asm__.
llvm-svn: 360503
The source uses C11 syntax such as comments and some compilers print
warnings without specifying this flag.
Differential Revision: https://reviews.llvm.org/D61797
llvm-svn: 360459
- Several "warning: extra ';' [-Wpedantic]"
- One "C++ style comments are not allowed in ISO C90 [enabled by default]"
in a file that uses C style comments everywhere but in one place
llvm-svn: 360430
Summary:
This allows libFuzzer to unpoison parameter shadow before calling
LLVMFuzzerTestOneInput to eliminate the false positives described
in https://github.com/google/oss-fuzz/issues/2369.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, metzman, kcc
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61751
llvm-svn: 360379
Summary:
... and its related functions.
The structure and its functionalities are identical to existing ones.
The header stores information on a `scudo::Chunk` to be able to detect
inconsitencies or potential corruption attempts. It is checksummed for
that purpose.
Reviewers: morehouse, eugenis, vitalybuka, hctim
Reviewed By: vitalybuka
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61654
llvm-svn: 360290
With recent changes the dev/nvmm/nvmm_ioctl.h header is no longer
a standalone NVMM header. Disable it until the NVMM operations will
stabilize and be included in the ioctl(2) interceptors.
llvm-svn: 360212
Summary:
The Quarantine is used to hold chunks for a little while prior to
actually releasing them for potential reuse. The code is pretty much
the same as the sanitizer_common one, with additional shuffling of
the quarantine batches to decrease predictability of allocation
patterns when it is enabled.
Reviewers: vitalybuka, eugenis, hctim, morehouse
Reviewed By: morehouse
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61385
llvm-svn: 360163
Summary:
I'm not aware of any platforms where this will work, but the code should at least compile.
HWASAN_WITH_INTERCEPTORS=OFF means there is magic in libc that would call __hwasan_thread_enter /
__hwasan_thread_exit as appropriate.
Reviewers: pcc, winksaville
Subscribers: srhines, kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61337
llvm-svn: 359914
Currently VMO in Zircon create using the zx_vmo_create is resizable
by default, but we'll be changing this in the future, requiring an
explicit flag to make the VMO resizable.
Prepare for this change by passing ZX_VMO_RESIZABLE option to all
zx_vmo_create calls that need resizable VMO.
Differential Revision: https://reviews.llvm.org/D61450
llvm-svn: 359803
This follows up after b7692bc3e9 "[UBSan] Fix
isDerivedFromAtOffset on iOS ARM64" fixed the RTTI comparison in
isDerivedFromAtOffset on just one platform and then
a25a2c7c9a "Always compare C++ typeinfo (based on
libstdc++ implementation)" extended that fix to more platforms.
But there is another RTTI comparison for -fsanitize=function generated in
clang's CodeGenFunction::EmitCall as just a pointer comparison. For
SANITIZER_NON_UNIQUE_TYPEINFO platforms this needs to be extended to also do
string comparison. For that, __ubsan_handle_function_type_mismatch[_abort]
takes the two std::type_info pointers as additional parameters now, checks them
internally for potential equivalence, and returns without reporting failure if
they turn out to be equivalent after all. (NORETURN needed to be dropped from
the _abort variant for that.) Also these functions depend on ABI-specific RTTI
now, so needed to be moved from plain UBSAN_SOURCES (ubsan_handlers.h/cc) to
UBSAN_CXXABI_SOURCES (ubsan_handlers_cxx.h/cc), but as -fsanitize=function is
only supported in C++ mode that's not a problem.
Differential Revision: https://reviews.llvm.org/D60760
llvm-svn: 359759
On Linux both version of the INTERCEPT_FUNCTION macro now return true
when interception was successful. Adapt and cleanup some usages.
Also note that `&(func) == &WRAP(func)` is a link-time property, but we
do a runtime check.
Tested on Linux and macOS.
Previous attempt reverted by: 5642c3feb0
This attempt to bring order to the interceptor macro goes the other
direction and aligns the Linux implementation with the way things are
done on Windows.
Reviewed By: vitalybuka, rnk
Differential Revision: https://reviews.llvm.org/D61358
llvm-svn: 359725
They need to have same AddressSpaceView and MapUnmapCallback.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61168
llvm-svn: 359719
Changing INTERCEPT_FUNCTION to return void is not functionally correct.
IMO the best way to communicate failure or success of interception is
with a return value, not some external address comparison.
This change was also creating link errors for _except_handler4_common,
which is exported from ucrtbase.dll in 32-bit Windows.
Also revert dependent changes r359362 and r359466.
llvm-svn: 359611
Summary:
Pass seed corpus list in a file to get around argument length limits on Windows.
This limit was preventing many uses of fork mode on Windows.
Reviewers: kcc, morehouse
Reviewed By: kcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D60980
llvm-svn: 359610
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.
This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.
Differential Revision: https://reviews.llvm.org/D28791
llvm-svn: 359591
Clang relies on existence of certain symbols that are normally
provided by crtbegin.o/crtend.o. However, LLVM does not currently
provide implementation of these files, instead relying on either
libgcc or implementations provided as part of the system.
This change provides an initial implementation of crtbegin.o/crtend.o
that can be used on system that don't provide crtbegin.o/crtend.o as
part of their C library.
Differential Revision: https://reviews.llvm.org/D28791
llvm-svn: 359576
Summary:
This CL implements the memory reclaiming function `releaseFreeMemoryToOS`
and its associated classes. Most of this code was originally written by
Aleksey for the Primary64 in sanitizer_common, and I made some changes to
be able to implement 32-bit reclaiming as well. The code has be restructured
a bit to accomodate for freelist of batches instead of the freearray used
in the current sanitizer_common code.
Reviewers: eugenis, vitalybuka, morehouse, hctim
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61214
llvm-svn: 359567
We have windows.h in asan_win.cc, so we can just use the correct
prototypes for these EH-related interceptors without worrying.
Also fix an unused variable warning while I'm here.
llvm-svn: 359500
HeapReAlloc should allow for 0 sized reallocations without freeing the memory block provided by the user.
_recalloc previously did not zero new memory after reallocation.
https://reviews.llvm.org/D61268
llvm-svn: 359498
Note that this change is not strictly NFC since we add the
`(&(name) != &WRAP(name)` part to the conditional for the `_VER` variant
of the macro.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D61204
llvm-svn: 359466
Symbol aliases are supported by all platforms that compiler-rt builtins
target, and we can use these instead of function redirects to avoid the
extra indirection.
This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".
Differential Revision: https://reviews.llvm.org/D60931
llvm-svn: 359413
Use the uniform single line C++/99 style for code comments.
This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".
Differential Revision: https://reviews.llvm.org/D60352
llvm-svn: 359411
Update formatting to use the LLVM style.
This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".
Differential Revision: https://reviews.llvm.org/D60351
llvm-svn: 359410
Summary: If bots work we can replace #ifs with template specialization by TwoLevelByteMapSize1.
There is known users of TwoLevelByteMap with TwoLevelByteMapSize1 equal 8,
and users of FlatByteMap with TwoLevelByteMapSize1 equal 2.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61200
llvm-svn: 359364
Fails on bots with:
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator_primary32.h:69:3: error: static_assert failed due to requirement 'TwoLevelByteMapSize1 > 128' "TwoLevelByteMap should be used"
static_assert(TwoLevelByteMapSize1 > 128, "TwoLevelByteMap should be used");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator_combined.h:29:34: note: in instantiation of template class '__sanitizer::SizeClassAllocator32<__sanitizer::AP32>' requested here
typename PrimaryAllocator::AddressSpaceView>::value,
^
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/13960/console
llvm-svn: 359352
I broke the build, panicked and applied the wrong fix in my previous
commit. The ASSERT was obsolete, but not the call INTERCEPT_FUNCTION.
llvm-svn: 359336
Summary: If bots work we can replace #ifs with template specialization by TwoLevelByteMapSize1.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61200
llvm-svn: 359333
This temporary change tells us about all the places where the return
value of the INTERCEPT_FUNCTION macro is actually used. In the next
patch I will cleanup the macro and remove GetRealFuncAddress.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D61145
llvm-svn: 359325
Summary:
The use case here is to be able get the UUIDs of the modules that need
to be symbolicated so that external plugins can see them. This
information can be extracted from ASan reports if the `print_module_map`
ASan option is enabled. Currently printing of the module map is only
implemented on Darwin and so this is effectively a Darwin only feature
right now.
The module map hooks into symbolization using the new plugin
infrastructure. A new hook in `AsanSymbolizerPlugInProxy` (and in
`AsanSymbolizerPlugIn`) is also provided to allow external plugins to hook
into the module look up process. This will allow external plugins to
look up modules with knowledge of their UUID.
The new plug-in is currently stored in the `asan_symbolize.py` script.
We could potentially move this into a separate file in the future (to
reduce clutter) if we can come up with a policy for where to search for
plugins that should always get loaded.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60531
llvm-svn: 359322
Originally this code as added for 64-bit platform and was never changed.
Add static_assert to make sure that we have correct map on all platforms.
llvm-svn: 359269
Summary:
Avoids an MSan false positive if the SIGINT comes while the user
callback is running. The false positive happens when the interrupt
handler calls opendir() to remove some temporary files, which is
intercepted by MSan.
Fixes https://github.com/google/oss-fuzz/issues/2332.
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits, Dor1s, metzman
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61163
llvm-svn: 359254
Summary:
As with the sanitizer_common allocator, the SCM allows for efficient
mapping between sizes and size-classes, table-free.
It doesn't depart significantly from the original, except that we
allow the use of size-class 0 for other purposes (as opposed to
chunks of size 0). The Primary will use it to hold TransferBatches.
Reviewers: vitalybuka, eugenis, hctim, morehouse
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61088
llvm-svn: 359199
(sanitizer-x86_64-linux) until I can triage the issue properly. The
build has been broken due to the symbolizer build checks failing.
As the symbolizer build script relies on the old svn repo layout, it may
take a little while longer to find the responsible patch for the
breakage. This may be a completely valid fix, but I will need to confirm
it. For now, it unbreaks the build.
Tracking data:
Build where the break first occurred: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/21211
Changelist authors: @grimar, @maskray, @whitequark, @spatel, @dpreobra
For the authors, no action needed (yet). Will follow up when I can
identify the cause.
llvm-svn: 359123
Summary:
The Secondary allocator wraps the platform allocation primitives. It is
meant to be used for larger sizes that the Primary can't fullfill, as
it will be slower, and sizes are multiple of the system page size.
This also changes some of the existing code, notably the opaque
platform data being passed to the platform specific functions: we can
shave a couple of syscalls on Fuchsia by storing additional data (this
addresses a TODO).
Reviewers: eugenis, vitalybuka, hctim, morehouse
Reviewed By: morehouse
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60787
llvm-svn: 359097
Calling `add_compiler_rt_component` sets up the component connection between runtime builds and the parent CMake configuration. Adding this call allows specifying `fuzzer` as a `LLVM_RUNTIME_DISTRIBUTION_COMPONENT`.
llvm-svn: 358780
Add close_fd_mask functionality to AFL driver.
Summary:
Add support for env var AFL_DRIVER_CLOSE_FD_MASK which behaves
the same as libFuzzer's -close_fd_mask=1.
Also add tests.
Reviewers: kcc, vitalybuka, morehouse
Reviewed By: morehouse
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D60334
llvm-svn: 358703
The change landed in r358657 broke some of the buildbots because they
use an older version of Python 2 that raises this error.
```
File "/Volumes/data/dev/llvm/upstream/master/src/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py", line 509
exec(f.read(), globals_space, None)
SyntaxError: unqualified exec is not allowed in function 'load_plugin_from_file' it contains a nested function with free variables
```
I can reproduce this problem when using Python 2.7.6.
To workaround this some indirection has been added to prevent the broken
(the line at fault would never be executed) SyntaxError error in old
Python versions from being raised.
rdar://problem/49476995
llvm-svn: 358682
Summary:
This change adds a simple plugin architecture to `asan_symbolize.py`.
The motivation here is that sometimes it's necessary to perform extra
work to figure out where binaries with debug symbols can actually be
found. For example it might be the case that a remote service needs
to be queried for binaries and then copied to the local system.
This "extra work" can be extremely site-specific such that adding the
code directly into the `asan_symbolize.py` would just clutter the code
for a very niche use case. To avoid this, the `asan_symbolize.py` can
now load external code via a new `--plugins` command line option.
These plugins are loaded before main command line argument parsing so
that they can add their own command line options.
Right now the only hook into the behaviour of symbolization is the
`filter_binary_path()` function which assumes a very similar role
to the `binary_name_filter` function that was previously in the code.
We can add more hooks as necessary.
Code in the `asan_symbolize.py` script does not call plugin code
directly. Instead it uses a `AsanSymbolizerPlugInProxy` object.
This object
* Loads plugins from files.
* Manages the lifetime of the plugins.
* Provides an interface for calling into plugin functions and handles
calling into multiple plugins.
To unify the way binary paths are filtered the old `sysroot_path_filter`
function (and associated code) has been turned into a simple plugin
(`SysRootFilterPlugIn`) that is always loaded. The plugin unloads
itself if the `-s` option is not present on the command line. Users
should not see any functional change relating to this command line
option.
Some simple tests are provided to illustrate what plugin code looks
like and also to check the functionality continues to work.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: srhines, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60529
llvm-svn: 358657
The generic version of comparesf2 defines __cmpsf2 alias for libgcc
compatibility, but the ARM overlay is missing the alias.
Differential Revision: https://reviews.llvm.org/D60805
llvm-svn: 358542
Summary: CFA was setup incorrectly, as there is an 8-byte gap at the top of the stack for SP 16-byte alignment purposes.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kubamracek, javed.absar, #sanitizers, llvm-commits, pcc
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D60798
llvm-svn: 358535
Summary:
1. Do not create DFSan labels for the bytes which we do not trace. This is where we run out of labels at the first place.
2. When dumping the traces on the disk, make sure to offset the label identifiers by the number of the first byte in the trace range.
3. For the last label, make sure to write it at the last position of the trace bit string, as that label represents the input size, not any particular byte.
Also fixed the bug with division in python which I've introduced when migrated the scripts to Python3 (`//` is required for integral division).
Otherwise, the scripts are wasting too much time unsuccessfully trying to
collect and process traces from the long inputs. For more context, see
https://github.com/google/oss-fuzz/issues/1632#issuecomment-481761789
Reviewers: kcc
Reviewed By: kcc
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60538
llvm-svn: 358311
Summary:
Before this change, MutateWithMask used to assert that Mask should be
of sufficient length (>= Size of the input). However, in real cases we may have
inputs that are longer than the Mask they have inherited from the based inputs.
Reviewers: kcc, morehouse
Reviewed By: kcc
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60571
llvm-svn: 358207
Summary:
In case the current corpus input doesn't have bytes going into the
focus function, MutateWithMask is useless and may fail gently, allowing the
default mutation routine happen, rather than crashing on an assertion.
For more context and the initial fix suggestion, see:
https://github.com/google/oss-fuzz/issues/1632#issuecomment-481862879
Reviewers: kcc, morehouse
Reviewed By: kcc
Subscribers: delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60567
llvm-svn: 358190
Summary:
As with other Sanitizers, and the current version of Scudo, we can
provide flags in differents way: at compile time, through a weak
function, through an environment variable.
This change adds support for the configuration flags, and the string
parsers. Those are fairly similar to the sanitizer_common way of doing
things.
Reviewers: morehouse, hctim, vitalybuka
Reviewed By: morehouse, vitalybuka
Subscribers: mgorny, delcypher, jdoerfert, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59597
llvm-svn: 358011
Summary:
This will make it easier to expand on the documentation in the future
that avoids cluttering the code.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60398
llvm-svn: 357978
Summary:
The previous logging infrastructure had several problems:
* Debugging output was emitted to standard output which is also where
the symbolized output would go. Interleaving these two separate
bits of information makes inspecting the output difficult and could
potentially break tests.
* Enabling debugging output requires modifying the script which is
not very conveninent.
* When debugging it isn't immediately obvious where the output is
coming from.
This patch uses the Python standard library logging infrastructure
which fixes all of the above problems. Logging is controlled using
two new options.
* `--log-level` - Sets the logging level, default is
`info`.
* `--log-dest` - Set the logging destination, default
is standard error.
Some simple test cases for the feature are included.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60343
llvm-svn: 357951
Summary:
r357240 added an interceptor for wctomb, which uses a temporary local
buffer to make sure we don't write to unallocated memory. This patch
applies the same technique to wcrtomb, and adds some additional tests
for this function.
Reviewers: vitalybuka, eugenis
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59984
llvm-svn: 357889
This is support for building compiler-rt builtins, The library build
should be complete for a subset of supported platforms, but not all
CMake options have been replicated in GN.
We always use the just built compiler to build all the runtimes, which
is equivalent to the CMake runtimes build. This simplifies the build
configuration because we don't need to support arbitrary host compiler
and can always assume the latest Clang. With GN's toolchain support,
this is significantly more efficient than the CMake runtimes build.
Differential Revision: https://reviews.llvm.org/D60331
llvm-svn: 357821
Summary:
When using libfuzzer on Windows, in the contents of a crash sample, bytes that can be mistaken for a \n are replaced by a \r\n sequence. As a consequence, crashes are not reproducible. This patch will open files in binary mode to fix this issue. The patch does not affect POSIX systems.
Patch by tuktuk
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: dexonsmith, jdoerfert, llvm-commits, #sanitizers
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60008
llvm-svn: 357807
Both LLVM 8.0.0 and current trunk fail to link libclang_rt.ubsan.standalone-*.so
on Solaris 11/x86 with GCC 8.1.0:
Undefined first referenced
symbol in file
Scanning dependencies of target clang_rt.asan_cxx-x86_64
__sanitizer::internal_dup(int) ../sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_posix.cc.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
make[2]: *** [projects/compiler-rt/lib/ubsan/CMakeFiles/clang_rt.ubsan_standalone-dynamic-i386.dir/build.make:233: lib/clang/9.0.0/lib/sunos/libclang_rt.ubsan_standalone-i386.so] Error 1
Fixed by providing an implementation, which allowed the i386-pc-solaris2.11 build
to finish.
Differential Revision: https://reviews.llvm.org/D60045
llvm-svn: 357753
Both LLVM 8.0.0 and current trunk fail to compile on Solaris 11/x86 with
GCC 8.1.0:
/vol/llvm/src/llvm/dist/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc: In function ‘void __sanitizer::ReExec()’:
/vol/llvm/src/llvm/dist/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:831:14: error: ‘getexecname’ was not declared in this scope
pathname = getexecname();
^~~~~~~~~~~
/vol/llvm/src/llvm/dist/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:831:14: note: suggested alternative: ‘gethostname’
pathname = getexecname();
^~~~~~~~~~~
gethostname
This is easily fixed by including <stdlib.h> which declares that function.
With that patch, compilation continues.
Differential Revision: https://reviews.llvm.org/D60044
llvm-svn: 357751
This avoids a conflict between stdbool.h, which defines bool to _Bool in
xkeycheck.h. From what I can tell, ymath.h is an internal header, and
the intention is that users should include math.h directly instead. It
doesn't appear to provide declarations of anything required for our
builtins. This include was added back in r249513 from 2015, and it's
possible that ymath.h provided something this code needed at the time,
but today it does not.
llvm-svn: 357728
llvm-ar is a crunchgen-style executable dispatching to dlltool,ranlib,lib,ar based on argv[0].
In our content-addressable storage, readlink -f resolves paths to some
digest and thus lost the original "llvm-ar" filename.
Replace it with a custom path resolution to fix the problem.
llvm-svn: 357450
Summary:
This is required to avoid msan false positives for code using this
function (although generally one should avoid using this function in
favor of wcrtomb).
Reviewers: eugenis, EricWF, vitalybuka
Subscribers: srhines, kubamracek, fedor.sergeev, delcypher, llvm-commits, #sanitizers
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59548
llvm-svn: 357240
Implement rounding mode support for addxf3/subxf3.
On architectures that implemented the support, this will access the
corresponding floating point environment register to apply the
correct rounding. For other architectures, it will keep the current
behaviour and use IEEE-754 default rounding mode (to nearest, ties
to even).
ARM32/AArch64 support implemented in this change. i386 and AMD64
will be added in a follow up change.
Differential Revision: https://reviews.llvm.org/D57143
llvm-svn: 357035
Also hide __cpu_inicator_init and __cpu_features2
for similar reasons.
Summary: Make __cpu_model a hidden symbol, to match libgcc.
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59561
llvm-svn: 356581
Summary:
This change adds fatal error messages for various error conditions that
will be added later in the code.
This also addresses a `TODO` now that we have `reportCheckFailed` (which
lead me to notice a few variables that were not cased properly so I
changed that as well).
Reviewers: morehouse, hctim, vitalybuka
Reviewed By: morehouse, hctim, vitalybuka
Subscribers: mgorny, delcypher, jfb, jdoerfert, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59551
llvm-svn: 356556
We were treating certain edge cases that are actually normal as denormal
results, and flushing them to zero; we shouldn't do that. Not sure this
is the cleanest way to implement this edge case, but I wanted to avoid
adding any code on the common path.
Differential Revision: https://reviews.llvm.org/D59070
llvm-svn: 356529
In libdispatch, dispatch_apply is implemented in terms of
dispatch_apply_f. Unfortunately, this means that we can't implement the
interceptor for dispatch_apply_f by forwarding to the dispatch_apply
interceptor.
In the interceptor dispatch_apply_f, we can't use WRAP(dispatch_apply).
WRAP(dispatch_apply) -> REAL(dispatch_apply_f). Requires duplication of
some setup code.
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D59526
llvm-svn: 356467
Summary:
Add some string utility functions, notably to format strings, get
lengths, convert a string to a number. Those functions will be
used in reports and flags (coming up next). They were mostly borrowed
from sanitizer_common.
Make use of the string length function in a couple places in the
platform code that was checked in with inlined version of it.
Add some tests.
Reviewers: morehouse, eugenis, vitalybuka, hctim
Reviewed By: morehouse, vitalybuka
Subscribers: mgorny, delcypher, jdoerfert, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59262
llvm-svn: 356457
When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library
now has a dependency on the blocks runtime and libdispatch. Make sure we
set all the required linking options.
Also add cmake options for specifying additional library paths to
instruct the linker where to search for libdispatch and the blocks
runtime. This allows us to build TSan runtime with libdispatch support
without installing those libraries into default linker library paths.
`CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid
aborting the build due to failing the link step in CMake's
check_c_compiler test.
Reviewed By: dvyukov, kubamracek
Differential Revision: https://reviews.llvm.org/D59334
llvm-svn: 356281
Including <dispatch/dispatch.h> and <Blocks.h> transitively pulls in
other system headers. Let's try to avoid that.
Blocks.h: compiler-rt already includes a blocks runtime. Just use the
header file that comes with it.
dispatch.h: Declare the bare minimum required for our implementation,
i.e., everything needed to define the interceptors, but not the
interceptors themselves. See tsan_dispatch_defs.h. I spotted a few other
places in compile-rt, where we declare libdispatch types. Maybe this
file can be moved to sanitizer_common if we deem it useful enough.
tsan_libdispatch.cc now compiles on Linux/Clang (requires support for
-fblocks). Linking still requires some manual configuration.
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D59145
llvm-svn: 356201
Summary:
Explicitly print 4 registers/line in each iteration during register
dump. Reduces logcat spam as we get a single logcat message per call to
Printf(), even if the output isn't newline-terminated. This brings the
output format in logcat closer to that of the normal textual dump.
Reviewers: eugenis, pcc
Reviewed By: pcc
Subscribers: kubamracek, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D59320
llvm-svn: 356166
Summary:
This patch contains the bits required to make the AddressSanitizer work on SPARC64/Linux (SPARC-T4 and later).
Patch by Eric Botcazou.
Reviewers: #sanitizers, vitalybuka, krytarowski
Reviewed By: #sanitizers, vitalybuka
Subscribers: brad, vitalybuka, ro, jyknight, kubamracek, fedor.sergeev, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58434
llvm-svn: 355980
Summary:
This patch contains a fixlet for the AddressSanitizer on the SPARC with GCC, which would otherwise generate a problematic call to the intercepted memcpy routine. It was tested with GCC on SPARC/Solaris and SPARC/Linux.
Patch by Eric Botcazou.
Reviewers: #sanitizers, vitalybuka
Reviewed By: #sanitizers, vitalybuka
Subscribers: vitalybuka, ro, jyknight, kubamracek, fedor.sergeev, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58433
llvm-svn: 355979
Summary:
This patch contains the bits required to make the common 32-bit allocator work on SPARC64/Linux.
Patch by Eric Botcazou.
Reviewers: #sanitizers, vitalybuka
Reviewed By: #sanitizers, vitalybuka
Subscribers: krytarowski, vitalybuka, ro, jyknight, kubamracek, fedor.sergeev, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58432
llvm-svn: 355978
Summary:
This patch contains various fixes for the unwinding and backtrace machinery on the SPARC, which doesn't work correctly in various cases. It was tested with GCC on SPARC/Solaris and SPARC/Linux.
Patch by Eric Botcazou.
Reviewers: #sanitizers, vitalybuka
Reviewed By: #sanitizers, vitalybuka
Subscribers: jrtc27, delcypher, vitalybuka, ro, jyknight, kubamracek, fedor.sergeev, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58431
llvm-svn: 355965
Summary:
This CL implements the checksumming functions. This departs from the
current Scudo code in one aspect: the software version is no longer
CRC32 but a BSD checksum. This is because the software CRC32 was too
impactful in terms of performances, the BSD checksum has no array
lookup which is better (and saves 1KB of data).
As with the current version, we only flip the CRC compiler flag for
a single compilation unit by default, to allow for a library compiled
with HW CRC32 to work on a system without HW CRC32.
There is some platform & hardware specific code in those files, but
since departs from a mere platform split, it felt right to me to have
it that way.
Reviewers: morehouse, eugenis, vitalybuka, hctim, mcgrathr
Reviewed By: morehouse
Subscribers: mgorny, delcypher, jfb, jdoerfert, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59116
llvm-svn: 355923
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:
This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance.
In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable.
The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format:
Registers where the failure occurred (pc 0x0055555561b4):
x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025
x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001
x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000
x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000
x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078
x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000
x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000
x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4
... and prints after the dump of memory tags around the buggy address.
Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging.
Reviewers: pcc, eugenis
Reviewed By: pcc, eugenis
Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58857
llvm-svn: 355738
On Linux (and other non-Darwin platforms) we need to initialize
interceptors. Since tsan_libdispatch.cc is compiled optionally, add a
weak default implementation of `InitializeLibdispatchInterceptors`.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D59113
llvm-svn: 355717
r355343 was landed and was reverted in r355363 due to build breakage.
This patch adds Linux/Windows support on top of r355343.
In this patch, Darwin should be working with testing case. Linux should be working,
I will enable the testing case in a follwup diff. Windows/Other should be building.
Correct implementation for Other platforms will be added.
Thanks David for reviewing the original diff, helping me with issues on Linux, and
giving suggestions for adding support for Other platforms.
llvm-svn: 355701
Summary:
This adds simple local & global stats classes to be used by the Primary
and Secondary, and associated test. Note that we don't need the strict
atomicity of the addition & subtraction (as is in sanitizer_common) so
we just use load & store.
Reviewers: morehouse, vitalybuka, eugenis, flowerhack, dmmoore415
Reviewed By: morehouse, vitalybuka
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D59031
llvm-svn: 355643
Most libdispatch functions come in two variants: callbacks can be
specified via blocks or function pointers. Some of our interceptors for
the block variant actually forward to the function variant. However, on
Linux, `DECLARE_REAL(name)` has to appear before `REAL(name)`.
This patch reorders _f variant interceptors before _b variants
where possible and forward declares the _f variant in the remaining
cases (cyclic dependency between _f and _b interceptors).
Also rename macro to DISPATCH_INTERCEPT_ASYNC_F for better consistency.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D59067
llvm-svn: 355619
This is a new attempt for bringing TSan libdispatch support to Linux.
The main issue with the last patch (https://reviews.llvm.org/D53171) was
that we want to avoid building a separate library.
The updated plan is as follows:
1) Hide libdispatch support behind a flag: true on Darwin, false
elsewhere. If flag is specified, assume that libdispatch header and
-flbocks is available for building. This way we can directly include
the libdispatch header and rely on blocks runtime for our
implementation.
2) Optionally/weakly intercept libdispatch API functions.
This patch accomplishes 1). It compiles (without the flag enabled) on
Linux. Follow-up patches will provide 2) and enabling of tests on Linux.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D58935
llvm-svn: 355538
Summary:
The bytemap classes will be used by the primary32 allocator to associate
classes with memory regions. It's similar to the sanitizer_common one
except for the fact that the base (level1) maps are mapped instead of
being static to reduce the memory footprint of an uninitialized allocator.
Reviewers: vitalybuka, eugenis, morehouse, flowerhack, dmmoore415, mcgrathr
Reviewed By: vitalybuka, morehouse
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58723
llvm-svn: 355416
The TraceLoggingProvider.h header does work with clang-cl in general
these days with Win SDK 10.0.17763.0, but when compiled in 32 bit x86
mode, with the -Z7 flag, compilation fails with the following error:
fatal error: error in backend: assembler label '' can not be undefined
With older Win SDKs, there are other build failures (regardless of
architecture or the -Z7 flag).
Differential Revision: https://reviews.llvm.org/D58958
llvm-svn: 355397
Cleanup ASan's __sanitizer::BufferedStackTrace::UnwindImpl (formerly
GetStackTrace) implementation. Start with ASan because it is the most
complex implementation.
GetStackTrace implementations seem to have started out as exact copies
of the original implementation in ASan, but have diverged in subtle
ways. My goal is to parameterize this algorithm (via templating or
callbacks) so we can share the implementation and get rid of the
inversed dependency (sanitizer_common depends on concrete
implementations in asan, ubsan, etc.). This should also help us to avoid
those pesky linker errors caused by undefined, duplicate, and weak
symbols on Windows.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D58861
llvm-svn: 355355
Summary:
They simply shuffle bits. MSan needs to do the same with shadow bits,
after making sure that the shuffle mask is fully initialized.
Reviewers: pcc, vitalybuka
Subscribers: hiraditya, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58858
llvm-svn: 355348
Breaks TSan on Mac, which does
return REAL(func)(...
in COMMON_INTERCEPTOR_ENTER, which is not OK when REAL(func) has return
type of void.
llvm-svn: 355256
macOS has implementation of LogFullErrorReport and
INLINE void LogFullErrorReport(const char *buffer) {}
was causing
> compiler-rt/lib/sanitizer_common/sanitizer_mac.cc:658:6: error: redefinition of 'LogFullErrorReport'
Fixup for r355236.
rdar://problem/48526020
llvm-svn: 355244
Replace remaining uses of old Unwind API in unit tests.
Allows us to remove the old API and WillUseFastUnwind can be made
private.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D58754
llvm-svn: 355242
mingw-w64 currently is lacking the headers for this feature.
Make the include lowercase at the same time. We consistently
use lowercase for windows header includes, as windows itself is
case insensitive, the SDK headers (in general, not necessarily
considering this particular header) aren't consistent among themselves
about what the proper canonical capitalization for headers are,
and MinGW uses all lowercase names for the headers (as it is often
used on case sensitive filesystems).
In case mingw-w64 later gets this header, we can revert this
(but keep the include lowercased).
Differential Revision: https://reviews.llvm.org/D58765
llvm-svn: 355236
GetStackTrace is a implementation detail of BufferedStackTrace. Make it
a private method.
Reviewed By: vitalybuka
Differential-Revision: https://reviews.llvm.org/D58753
llvm-svn: 355232
Summary:
A missing `STATIC` entailed some annoying to debug failures wrt 32 vs 64
binaries. Additionally I noticed I was using the wrong variable (the Scudo
one as opposed to the Scudo Standalone one).
See https://reviews.llvm.org/D58184#1412417 and below for discussion.
Reviewers: vitalybuka, eugenis, brzycki
Reviewed By: vitalybuka, brzycki
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58794
llvm-svn: 355203
Retrying without replacing call sites in sanitizer_common (which might
not have a symbol definition).
Add new Unwind API. This is the final envisioned API with the correct
abstraction level. It hides/slow fast unwinder selection from the caller
and doesn't take any arguments that would leak that abstraction (i.e.,
arguments like stack_top/stack_bottom).
GetStackTrace will become an implementation detail (private method) of
the BufferedStackTrace class.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58741
> llvm-svn: 355168
llvm-svn: 355172
Add new Unwind API. This is the final envisioned API with the correct
abstraction level. It hides/slow fast unwinder selection from the caller
and doesn't take any arguments that would leak that abstraction (i.e.,
arguments like stack_top/stack_bottom).
GetStackTrace will become an implementation detail (private method) of
the BufferedStackTrace class.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58741
llvm-svn: 355168
Summary:
This fixes inconsistent symbol visibility. This shows up as a linker
warning if r336238 (43f633564e338a6dde83d49a48e5bfcbfdce292c) is
reverted.
```
ld: warning: direct access in function 'fuzzer::CleanseCrashInput(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, fuzzer::FuzzingOptions const&)' from file '/Volumes/data/dev/llvm/upstream/master/builds/projects/compiler-rt/lib/fuzzer/tests/libRTFuzzerTest.x86_64.a(FuzzerDriver.cpp.o)' to global weak symbol 'fuzzer::Command::ignoreRemainingArgs()::kIgnoreRemaining' from file 'FuzzerTestObjects.FuzzerUnittest.cpp.x86_64.o' means the weak symbol cannot be overridden
at runtime. This was likely caused by different translation units being compiled with different visibility settings.
```
r336238 just hid the issue rather than fixing the real issue. On macOS
and other platforms we usually compile with `-fvisibility=hidden` but
the unit tests were compiled without this flag.
Reviewers: george.karpenkov, kubamracek, kcc, yln
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58055
llvm-svn: 355143
Remove the maximum stack cleanup size check. With ulimit -s unlimited
main thread stack can be very large, but we don't really have a choice
other than cleaning all of it. It should be reasonably fast - hwasan
cleans large shadow ranges with a single madvise call.
This change fixes check-hwasan after ulimit -s unlimited.
llvm-svn: 355137
This reverts revision 354601 and disables ReadBinaryNameCached check on
Windows since Windows has no working ReadBinaryName.
Differential Revision: https://reviews.llvm.org/D58788
llvm-svn: 355129
PLT calls on i386 expect GOT base address in %ebx.
This call does not need to go through PLT strictly speaking, but I'd
rather avoid future surprises and implement the most general case.
llvm-svn: 355125
The concept of weak linkage is not available on Windows. The available
workarounds in LLVM/sanitizer runtimes have their own problems. Define a
separte symbol ubsan_GetStackTrace to work around the issue now. At lest
this way it is painfully obvious that we still have to do more cleanup.
Follow-up to revision: https://reviews.llvm.org/D58651
llvm-svn: 355113
Adds option for collecting sanitixer dumps via trace logging.
- Set log_to_syslog=1 to enable this output.
- Consult https://aka.ms/windowstracelogging for details on use.
llvm-svn: 355045
Disable hwasan interceptor on non-linux, non-x86-or-arm platforms.
Add @plt to the asm call that clang intergrated-as infers but gcc does
not.
llvm-svn: 355041
We already independently declare GetStackTrace in all (except TSan)
sanitizer runtime headers. Lets move it to sanitizer_stacktrace.h to
have one canonical way to fill in a BufferedStackFrame. Also enables us
to use it in sanitizer_common itself.
This patch defines GetStackTrace for TSan and moves the function from
ubsan_diag.cc to ubsan_diag_standalone.cc to avoid duplicate symbols
for the UBSan-ASan runtime.
Other than that this patch just moves the code out of headers and into
the correct namespace.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58651
llvm-svn: 355039
Also assert that the caller always gets what it requested.
This purely mechanical change simplifies future refactorings and
eventual removal of BufferedStackTrace::Unwind.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58557
llvm-svn: 355022
Summary:
Port libFuzzer's fork mode to Windows.
Implement Windows versions of MkDir, RmDir, and IterateDirRecursive to do this.
Don't print error messages under new normal uses of FileSize (on a non-existent file).
Implement portable way of piping output to /dev/null.
Fix test for Windows and comment fork-sigusr.test on why it won't be ported to Win.
Reviewers: zturner
Reviewed By: zturner
Subscribers: kcc, zturner, jdoerfert, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58513
llvm-svn: 355019
Summary:
This CL adds a standalone vector class that will be used by the scoped
strings when they land. We reimplement our own vector class because we
can't use the std library one.
It's mostly borrowed from the current sanitizer_common one, with LLVM
code style changes.
Additionnally a casing change in a function name that slipped through
the previous review (the function isn't used yet).
Reviewers: vitalybuka, eugenis, flowerhack, dmmoore415, mcgrathr, morehouse
Reviewed By: vitalybuka
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58689
llvm-svn: 354999
As discussed elsewhere: LLVM uses cpp as its C++ source extension; the
sanitizers should too. This updates files in hwasan.
Patch generated by
for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done
followed by
for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done
CMakeLists.txt updated manually.
Differential Revision: https://reviews.llvm.org/D58620
llvm-svn: 354989
For 'cascadelake' this is adding a 'avx512vnni' feature check to the 0x55 skylake-avx512 model check. These CPUs use the same model number and only differ in the stepping number. But the feature flag is simpler than collecting all the stepping numbers.
For 'znver2' this is just syncing with LLVM's Host.cpp.
llvm-svn: 354927
Summary:
When running the standalone main on a large corpus, I eventually get a
EMFILE error ("Too many open files").
Patch by Paul Chaignon
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: lebedev.ri, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58622
llvm-svn: 354918
Summary:
This CL adds the platform specific code for Fuchsia, Linux & Android,
as well as some tests related to those (more tests to come later).
While some of it is pretty much a straight port of the existing scudo &
sanitizer_common code, the memory mapping functions have been reworked
a bit to fit the limited usage scenario that Scudo has for them.
For Fuchsia, I can now track the Vmar/Vmo pair for memory mappings if
there is an intent to grow or decommit some mapping (that will be
useful for the Primary).
Reviewers: eugenis, vitalybuka, mcgrathr, phosek, flowerhack, morehouse, dmmoore415
Reviewed By: vitalybuka, morehouse
Subscribers: kcc, dvyukov, srhines, mgorny, delcypher, jfb, jdoerfert, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58184
llvm-svn: 354895
Summary:
pthread_sigmask is just like sigprocmask, except that its behavior in
multithreaded programs is explicitly specified. Sanitizers were lacking
a common interceptor for pthread_sigmask (although some specific
sanitizers defined custom version), which lead to false positives
(at least in msan) when using this function.
The interceptor implementation, and its test are based on the equivalent
code for sigprocmask.
Reviewers: eugenis, vitalybuka
Subscribers: kubamracek, delcypher, jfb, jdoerfert, llvm-commits, #sanitizers
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58382
llvm-svn: 354874
Summary:
I have not introduced a separate hook for `bcmp()` as I don't think there
should be any reason for a sanitizer to treat it differently from `memcmp()`.
This is only enabled when building on POSIX with GNU extensions.
Context: this is to avoid losing coverage when emitting `bcmp() == 0` instead
of `memcmp() == 0` in llvm, see https://reviews.llvm.org/D56593.
Reviewers: mgorny, krytarowski, vitalybuka, dvyukov
Subscribers: kubamracek, dberris, delcypher, jdoerfert, #sanitizers, llvm-commits, jyknight
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D58379
llvm-svn: 354851
Summary:
The llvm-cov tool needs to be able to find coverage names in the
executable, so the .lprfn and .lcovmap sections cannot be merged into
.rdata.
Also, the linker merges .lprfn$M into .lprfn, so llvm-cov needs to
handle that when looking up sections. It has to support running on both
relocatable object files and linked PE files.
Lastly, when loading .lprfn from a PE file, llvm-cov needs to skip the
leading zero byte added by the profile runtime.
Reviewers: vsk
Subscribers: hiraditya, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58661
llvm-svn: 354840
This is a second attempt at r342652 using a TLS callback instead of an
interceptor.
In long-running builds we've seen some ASan complaints during thread creation
that we suspect are due to leftover poisoning from previous threads whose
stacks occupied that memory. This patch adds a callback that unpoisons the
stack memory when a thread exits.
Differential Revision: https://reviews.llvm.org/D58641
llvm-svn: 354836
FastUnwindStack -> UnwindFast
SlowUnwindStack -> UnwindSlow
Stack is redundant, verb should come first.
SlowUnwindStackWithContext(uptr pc, void *context, u32 max_depth) ->
SlowUnwindStack
WithContext is redundant, since it is a required parameter.
Reviewers: vitalybuka
Differential Revision: https://reviews.llvm.org/D58551
llvm-svn: 354696
__asan_handle_vfork was unpoisoning the wrong part of the stack.
Adjust the test to catch this reliably (current failure is
non-deterministic).
llvm-svn: 354627
In compiler-rt we have the notion of a `fast` and a `slow` stack
unwinder. Darwin currently only supports the fast unwinder.
From reading the code, my understanding is that
`BufferedStackTrace::Unwind` can be called with `bp=0, stack_top=0,
stack_bottom=0, request_fast_unwind=false`. If
`request_fast_unwind=true`, then we alos need to supply bp, stack_top,
and stack_bottom.
However, `BufferedStackTrace::Unwind` uses
`StackTrace::WillUseFastUnwind` which will adapt `request_fast_unwind`
if the requested unwinder is not supported. On Darwin, the result is
that we don't pass actual values for bp, stack_top, and stack_bottom,
but end up using the fast unwinder. The tests then fail because we only
print the topmost stack frame.
This patch adds a check to `WillUseFastUnwind` at the point of usage to
avoid the mismatch between `request_fast_unwind` and what `Unwind`
actually does. I am also interested in cleaning up the
`request_fast_unwind` machinery so this patch just the simplest thing
possible so I can enable the tests.
Reviewers: vitalybuka, vsk
Differential Revision: https://reviews.llvm.org/D58156
llvm-svn: 354282
According to the logs and local debugging there were two issues:
1) tsan tests listed libc++.a before the source file. That's usually
ok for shared libraries, but the linker will not add symbols from
a static library unless needed at that time. As a result the tests
that rely upon symbols from the library (and not only include the
headers) had undefined references.
To solve this I'm adding a new substitution %link_libcxx_tsan which
expands to libc++.a if available.
2) The target Fuzzer-x86_64-Test linked in SANITIZER_TEST_CXX_LIBRARIES
which defaults to -lstdc++. This resulted in error messages like
hidden symbol '_ZdlPv' is not defined locally
hidden symbol '_Znwm' is not defined locally
when using GNU gold (ld.bfd and lld are fine). Removing the linkage
is fine because we build a custom libc++ for that purpose.
llvm-svn: 354231
This changes add_custom_libcxx to also build libcxxabi and merges
the two into a static and hermetic library.
There are multiple advantages:
1) The resulting libFuzzer doesn't expose C++ internals and looks
like a plain C library.
2) We don't have to manually link in libstdc++ to provide cxxabi.
3) The sanitizer tests cannot interfere with an installed version
of libc++.so in LD_LIBRARY_PATH.
Differential Revision: https://reviews.llvm.org/D58013
llvm-svn: 354212
Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking
unit tests. This needs to be a full C++ library and cannot be libcxxabi.
Recommit r354132 which I reverted in r354153 because it broke a sanitizer
bot. This was because of the "fixes" for pthread linking, so I've removed
these changes.
Differential Revision: https://reviews.llvm.org/D58012
llvm-svn: 354198
There is an ambiguity between ::SizeClassMap (the typedef declared near
the start of this file) and __sanitizer::SizeClassMap (found by the
'using namespace __sanitizer;' near the start of this file).
Historically a Clang bug has meant that the error was not diagnosed, but
soon Clang will start diagnosing it. Explicitly qualify this use of
SizeClassMap so that it finds __sanitizer::SizeClassMap rather than
being ill-formed due to ambiguity.
llvm-svn: 354174
Summary:
When symbols are unavailable, the current code prints
sp: ... pc: ... (null) (null)
instead of module name + offset.
Change the output to include module name and offset, and also to match
the regular sanitizer stack trace format so that it is recognized by
symbolize.py out of the box.
Reviewers: kcc, pcc
Subscribers: kubamracek, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58267
llvm-svn: 354157
Summary:
With tag_in_free=1, malloc() can not assume that the memory is untagged,
and needs to retag is to 0.
Reviewers: pcc, kcc
Subscribers: kubamracek, jfb, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58158
llvm-svn: 354155
Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking
unit tests. This needs to be a full C++ library and cannot be libcxxabi.
Differential Revision: https://reviews.llvm.org/D58012
llvm-svn: 354132
Kostya Kortchinsky