Make it possible to control building profile runtime separately from
other options. Before r313549, the profile runtime building was
controlled along with sanitizers. However, since that commit it is built
unconditionally which results in multiple builds for people building
different runtimes separately.
Differential Revision: https://reviews.llvm.org/D38441
llvm-svn: 314646
This should fix an issue which arises when running check-compiler-rt on
the coverage bot:
http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1590/
The bot doesn't build the sanitizers, but the check-compiler-rt target
always expects the profile runtime to exist.
llvm-svn: 313549
Resulting library binaries will be named libclang_rt.fuzzer*, and will
be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.llvm.org/D36908
llvm-svn: 311407
Summary: Cleaner than computing the intersection for each possible sanitizer
Reviewers: compnerd, beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34693
llvm-svn: 306453
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd, rnk, pcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306450
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306415
Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes
either a special token `all` (default) which will preserve the current behaviour
or a CMake list of sanitizers to build. It will still perform the normal checks
if the sanitizer is requested. It only permits a further means to exclude a
particular sanitizer. This gives finer grained control than
`COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control.
llvm-svn: 279253
Summary:
This is a fixed-up version of D21612, to address failure identified post-commit.
Original commit description:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Fixes include:
- Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built
- Including <cstddef> to fix std::size_t issue
Reviewers: kcc, rnk, echristo
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D22611
llvm-svn: 276251
and also the follow-up "[xray] Only build xray on Linux for now"
Two build errors were reported on the llvm-commits list:
[ 88%] Building CXX object lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_flags.cc.o
/mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/xray/xray_init.cc:23:10: fatal error: 'llvm/Support/ELF.h' file not found
#include "llvm/Support/ELF.h"
^
and
In file included from /w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface.cc:16:
/w/src/llvm.org/projects/compiler-rt/lib/xray/xray_interface_internal.h:36:8: error:
no type named 'size_t' in namespace 'std'
std::size_t Entries;
~~~~~^
llvm-svn: 276186
Should fix the Windows buildbots, and maybe some other non-Linux Unix
bots too.
XRay currently depends on sanitizer_common, so associate it with the
"build sanitizers" option and remove the option for separately
controlling the XRay build.
llvm-svn: 276124
Summary:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Depends on D19904
Reviewers: echristo, kcc, rnk
Subscribers: rnk, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D21612
llvm-svn: 276117
Summary:
This is an initial implementation of a Hardened Allocator based on Sanitizer Common's CombinedAllocator.
It aims at mitigating heap based vulnerabilities by adding several features to the base allocator, while staying relatively fast.
The following were implemented:
- additional consistency checks on the allocation function parameters and on the heap chunks;
- use of checksum protected chunk header, to detect corruption;
- randomness to the allocator base;
- delayed freelist (quarantine), to mitigate use after free and overall determinism.
Additional mitigations are in the works.
Reviewers: eugenis, aizatsky, pcc, krasin, vitalybuka, glider, dvyukov, kcc
Subscribers: kubabrecka, filcab, llvm-commits
Differential Revision: http://reviews.llvm.org/D20084
llvm-svn: 271968
Summary:
Adds the initial version of a runtime library for the new
EfficiencySanitizer ("esan") family of tools. The library includes:
+ Slowpath code via callouts from the compiler instrumentation for
each memory access.
+ Registration of atexit() to call finalization code.
+ Runtime option flags controlled by the environment variable
ESAN_OPTIONS. The common sanitizer flags are supported such as
verbosity and log_path.
+ An initial simple test.
Still TODO: common code for libc interceptors and shadow memory mapping,
and tool-specific code for shadow state updating.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, vkalintiris, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19168
llvm-svn: 267060
This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.
Differential Revision: http://reviews.llvm.org/D16176
llvm-svn: 257972
This is an initial version of the runtime cross-DSO CFI support
library.
It contains a number of FIXMEs, ex. it does not support the
diagnostic mode nor dlopen/dlclose, but it works and can be tested.
Diagnostic mode, in particular, would require some refactoring (we'd
like to gather all CFI hooks in the UBSan library into one function
so that we could easier pass the diagnostic information down to
__cfi_check). It will be implemented later.
Once the diagnostic mode is in, I plan to create a second test
configuration to run all existing tests in both modes. For now, this
patch includes only a few new cross-DSO tests.
llvm-svn: 255695
Summary:
Rather than having to add new "experimental" options each time someone wants to work on bringing a sanitizer to a new platform, this patch makes options for all of them.
The default values for the options are set by the platform checks that would have enabled them, but they can be overridden on or off.
Reviewers: kubabrecka, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14846
llvm-svn: 255170
There are situations where a user may want to build only the compiler-rt builtins, or only the sanitizer runtimes. This exposes options to do that. Both default to On, so there should be no implicit change in behavior.
llvm-svn: 247607
This patch adds runtime support for the Safe Stack protection to compiler-rt
(see http://reviews.llvm.org/D6094 for the detailed description of the
Safe Stack).
This patch is our implementation of the safe stack on top of compiler-rt. The
patch adds basic runtime support for the safe stack to compiler-rt that
manages unsafe stack allocation/deallocation for each thread.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6096
llvm-svn: 239763
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change
doesn't modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, rsmith, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8646
llvm-svn: 233861
MSanDR is a dynamic instrumentation tool that can instrument the code
(prebuilt libraries and such) that could not be instrumented at compile time.
This code is unused (to the best of our knowledge) and unmaintained, and
starting to bit-rot.
llvm-svn: 222232
a given platform in a top-level CMakeLists.txt to use it both
in lib/ and in test/ subdirectories. Move architecture/platform
checks to config-ix.
llvm-svn: 215247
This change allows to build compiler-rt libraries separately from
LLVM/Clang (path to LLVM build directory should be specified at
configure time). Running tests is not yet supported.
llvm-svn: 201647
Adding the ARM RT sources to the CMake files, and enabling some
sanitizers to also build on ARM. This is far from supported or
production quality, but enabling it to build will get us errors
that we can actually fix.
Having said that, the Compiler-RT and the Asan libraries are
know to work on some variations of ARM.
llvm-svn: 200546
This sets flags and excludes things that aren't working with MSVC yet,
allowing us to build the ASan runtime as part of the cmake build.
Differential Revision: http://llvm-reviews.chandlerc.com/D1525
llvm-svn: 189304
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D967
llvm-svn: 187924
Michal Gorny