Handle it in the driver and propagate it to cc1
Reviewers: rjmccall, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52615
llvm-svn: 346001
Boilerplate code for using KMSAN instrumentation in Clang.
We add a new command line flag, -fsanitize=kernel-memory, with a
corresponding SanitizerKind::KernelMemory, which, along with
SanitizerKind::Memory, maps to the memory_sanitizer feature.
KMSAN is only supported on x86_64 Linux.
It's incompatible with other sanitizers, but supports code coverage
instrumentation.
llvm-svn: 341641
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:
```
unsigned char store = 0;
bool consume(unsigned int val);
void test(unsigned long val) {
if (consume(val)) {
// the 'val' is `unsigned long`, but `consume()` takes `unsigned int`.
// If their bit widths are different on this platform, the implicit
// truncation happens. And if that `unsigned long` had a value bigger
// than UINT_MAX, then you may or may not have a bug.
// Similarly, integer addition happens on `int`s, so `store` will
// be promoted to an `int`, the sum calculated (0+768=768),
// and the result demoted to `unsigned char`, and stored to `store`.
// In this case, the `store` will still be 0. Again, not always intended.
store = store + 768; // before addition, 'store' was promoted to int.
}
// But yes, sometimes this is intentional.
// You can either make the conversion explicit
(void)consume((unsigned int)val);
// or mask the value so no bits will be *implicitly* lost.
(void)consume((~((unsigned int)0)) & val);
}
```
Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, there are cases where it does **not** warn.
So a Sanitizer is needed. I don't have any motivational numbers, but i know
i had this kind of problem 10-20 times, and it was never easy to track down.
The logic to detect whether an truncation has happened is pretty simple
if you think about it - https://godbolt.org/g/NEzXbb - basically, just
extend (using the new, not original!, signedness) the 'truncated' value
back to it's original width, and equality-compare it with the original value.
The most non-trivial thing here is the logic to detect whether this
`ImplicitCastExpr` AST node is **actually** an implicit conversion, //or//
part of an explicit cast. Because the explicit casts are modeled as an outer
`ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children.
https://godbolt.org/g/eE1GkJ
Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set
on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`.
So if that flag is **not** set, then it is an actual implicit conversion.
As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`.
There are potentially some more implicit conversions to be warned about.
Namely, implicit conversions that result in sign change; implicit conversion
between different floating point types, or between fp and an integer,
when again, that conversion is lossy.
One thing i know isn't handled is bitfields.
This is a clang part.
The compiler-rt part is D48959.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions)
Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane
Reviewed By: rsmith, vsk, erichkeane
Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D48958
llvm-svn: 338288
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
llvm-svn: 335569
Summary:
This is the clang side of the change, there is a compiler-rt counterpart.
Scudo works with UBSan using `-fsanitize=scudo,integer` for example, and to do
so it embeds UBSan runtime. This makes it not compatible with the UBSan minimal
runtime, but this is something we want for production purposes.
The idea is to have a Scudo minimal runtime on the compiler-rt side that will
not embed UBSan. This is basically the runtime that is currently in use for
Fuchsia, without coverage, stacktraces or symbolization. With this, Scudo
becomes compatible with `-fsanitize-minimal-runtime`.
If this approach is suitable, I'll add the tests as well, otherwise I am open
to other options.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D48373
llvm-svn: 335352
NFC for targets other than PS4.
This patch is a change in behavior for PS4, in that PS4 will no longer enable
RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default
on PS4). RTTI will remain disabled except for types being thrown or caught.
Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted,
as it is for other targets.
This patch removes some PS4 specific code, making the code cleaner.
Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the
same as the generic x86_64-linux are removed, making the test cleaner.
Differential Revision: https://reviews.llvm.org/D46982
llvm-svn: 332784
Currently LLVM CFI tries to use an implicit blacklist file, currently
in /usr/lib64/clang/<version>/share. If the file is not there, LLVM
happily continues, which causes CFI to add checks to files/functions
that are known to fail, generating binaries that fail. This CL causes
LLVM to die (I hope) if it can't find these implicit blacklist files.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D46403
llvm-svn: 331674
The implementation of shadow call stack on aarch64 is quite different to
the implementation on x86_64. Instead of reserving a segment register for
the shadow call stack, we reserve the platform register, x18. Any function
that spills lr to sp also spills it to the shadow call stack, a pointer to
which is stored in x18.
Differential Revision: https://reviews.llvm.org/D45239
llvm-svn: 329236
Summary:
Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.
Reviewers: pcc, kcc
Reviewed By: pcc, kcc
Subscribers: cryptoad, cfe-commits, kcc
Differential Revision: https://reviews.llvm.org/D44801
llvm-svn: 329122
Summary: Porting HWASan to Linux x86-64, the third of the three patches, clang part.
Reviewers: eugenis
Subscribers: cryptoad, cfe-commits
Differential Revision: https://reviews.llvm.org/D44745
llvm-svn: 328361
When a sanitizer incompatible with one of the default sanitizers
is explicitly enabled, automatically disable all the conflicting
default sanitizers.
Differential Revision: https://reviews.llvm.org/D44064
llvm-svn: 326860
This allows reporting an error when user tries to use SafeStack with
incompatible sanitizers.
Differential Revision: https://reviews.llvm.org/D43606
llvm-svn: 326151
Ideally, we'd only use the ubsan blacklist for ubsan sanitizers, and only use
the other-sanitizer blacklist for its sanitizers, but this at least enables the
intended suppressions.
llvm-svn: 325640
Summary:
This change adds Scudo as a possible Sanitizer option via -fsanitize=.
This allows for easier static & shared linking of the Scudo library, it allows
us to enforce PIE (otherwise the security of the allocator is moot), and check
for incompatible Sanitizers combo.
In its current form, Scudo is not compatible with any other Sanitizer, but the
plan is to make it work in conjunction with UBsan (-fsanitize=scudo,undefined),
which will require additional work outside of the scope of this change.
Reviewers: eugenis, kcc, alekseyshl
Reviewed By: eugenis, alekseyshl
Subscribers: llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D39334
llvm-svn: 317337
Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
Summary:
Also enable -no-pie on Gnu toolchain (previously available on Darwin only).
Non-PIE executables won't even start on recent Android, and DT_RPATH is ignored by the loader.
Reviewers: srhines, danalbert
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38430
llvm-svn: 316606
Summary:
The OS provides cross-dso CFI support starting with Android O.
Trapping mode does not require any runtime at all, and diagnostic mode
requires just ubsan-standalone.
Reviewers: pcc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38908
llvm-svn: 315921
Summary:
* Rename -shared-libasan to -shared-libsan, keeping the old name as alias.
* Add -static-libsan for targets that default to shared.
* Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there.
* Support libclang_rt.ubsan_standalone as a shared library.
Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers.
I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers
are not compatible with each other, and each link has basically a single shared/static choice.
Reviewers: vitalybuka, kcc, rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38525
llvm-svn: 315015
Summary:
An implementation of ubsan runtime library suitable for use in production.
Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general.
* as simple as possible
Minimal CPU and RAM overhead.
* Source locations unnecessary in the presence of (split) debug info.
* Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at.
* above two items save 3% binary size.
When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt.
Reviewers: pcc, kcc
Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D36810
llvm-svn: 312029
Summary:
Augment SanitizerCoverage to insert maximum stack depth tracing for
use by libFuzzer. The new instrumentation is enabled by the flag
-fsanitize-coverage=stack-depth and is compatible with the existing
trace-pc-guard coverage. The user must also declare the following
global variable in their code:
thread_local uintptr_t __sancov_lowest_stack
https://bugs.llvm.org/show_bug.cgi?id=33857
Reviewers: vitalybuka, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, hiraditya, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D36839
llvm-svn: 311186
The flag will perform instrumentation necessary to the fuzzing,
but will NOT link libLLVMFuzzer.a library.
Necessary when modifying CFLAGS for projects which may produce
executables as well as a fuzzable target.
Differential Revision: https://reviews.llvm.org/D36600
llvm-svn: 310733
Peter Collingbourne