| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
This happens on a 64-bit platform that uses SizeClassAllocator32 (e.g. ASan on AArch64). When querying a large invalid pointer, `__sanitizer_get_allocated_size(0xdeadbeefdeadbeef)`, an assertion will fail. This patch changes PointerIsMine to return false if the pointer is outside of [kSpaceBeg, kSpaceBeg + kSpaceSize).
Differential Revision: http://reviews.llvm.org/D15008
llvm-svn: 268243
|
|
|
|
|
|
|
|
| |
There is a hard-to-reproduce crash happening on OS X that involves terminating the main thread (dispatch_main does that, see discussion at http://reviews.llvm.org/D18496) and later reusing the main thread's ThreadContext. This patch disables reuse of the main thread. I believe this problem exists only on OS X, because on other systems the main thread cannot be terminated without exiting the process.
Differential Revision: http://reviews.llvm.org/D19722
llvm-svn: 268238
|
|
|
|
| |
llvm-svn: 268046
|
|
|
|
|
|
| |
Recent TSan changes (r267678) which factor out parts of ThreadState into a Processor structure broke worker threads on OS X. This fixes it by properly calling ProcCreate for GCD worker threads and by replacing some CHECKs with RAW_CHECK in early process initialization. CHECK() in TSan calls the allocator, which requires a valid Processor.
llvm-svn: 267864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
involved.
On linux, some architectures had an ABI transition from 64-bit long double
(ie. same as double) to 128-bit long double. On those, glibc symbols
involving long doubles come in two versions, and we need to pass the
correct one to dlvsym when intercepting them.
A few more functions we intercept are also versioned (all printf, scanf,
strtold variants), but there's no need to fix these, as the REAL() versions
are never called.
Differential Revision: http://reviews.llvm.org/D19555
llvm-svn: 267794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The strchr and strrchr interceptors are sometimes invoked too early
for their REAL() counterparts to be initialized. We have seen this in
hooks invoked from tcmalloc on the dlsym() used in initializing
interceptors. A special check is added to use internal_ routines for
this situation.
Reviewers: vitalybuka, aizatsky, filcab
Subscribers: filcab, llvm-commits, eugenis, kcc, zhaoqin, aizatsky, kubabrecka
Differential Revision: http://reviews.llvm.org/D19607
llvm-svn: 267793
|
|
|
|
|
|
|
|
|
|
| |
Summary: Resubmit of http://reviews.llvm.org/D19495 enabled only on intel.
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19561
llvm-svn: 267750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In short, CVE-2016-2143 will crash the machine if a process uses both >4TB
virtual addresses and fork(). ASan, TSan, and MSan will, by necessity, map
a sizable chunk of virtual address space, which is much larger than 4TB.
Even worse, sanitizers will always use fork() for llvm-symbolizer when a bug
is detected. Disable all three by aborting on process initialization if
the running kernel version is not known to contain a fix.
Unfortunately, there's no reliable way to detect the fix without crashing
the kernel. So, we rely on whitelisting - I've included a list of upstream
kernel versions that will work. In case someone uses a distribution kernel
or applied the fix themselves, an override switch is also included.
Differential Revision: http://reviews.llvm.org/D19576
llvm-svn: 267747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UnmapOrDie used to do MEM_DECOMMIT and so worked
on partial regions. But r263160 changed it to use
MEM_RELEASE and MEM_RELEASE can only work with
whole regions mapped by VirtualAlloc. This broke
windows as:
FATAL: ThreadSanitizer CHECK failed: gotsan.cc:8296 "((mbi.AllocationBase == addr && "Windows cannot unmap part of a previous mapping")) != (0)" (0x0, 0x0)
Restore the previous behavior.
llvm-svn: 267730
|
|
|
|
|
|
|
|
| |
os_trace turns out to be a macro that creates static object.
Function-static objects use __cxa_atexit and __dso_handle
which are not present in Go runtime.
llvm-svn: 267720
|
|
|
|
|
|
| |
syslog_lock is not defined in Go build.
llvm-svn: 267714
|
|
|
|
|
|
|
|
| |
Ifdef out global variables with destructors.
This requires runtime support that is not provided by Go runtime
(in particular _dso_handle symbol).
llvm-svn: 267709
|
|
|
|
|
| |
warning: '__sanitizer::uptr __sanitizer::GetPreferredBase(const char*)' defined but not used
llvm-svn: 267682
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19542
llvm-svn: 267586
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19134
llvm-svn: 267548
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19159
llvm-svn: 267547
|
|
|
|
|
|
|
|
|
| |
This reverts commit r267477.
It broke our bots that enables the AArch64 backends, it seems that
this code is using a Darwin *X86 specific* field.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267526
|
|
|
|
|
|
|
|
| |
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19495
llvm-svn: 267477
|
|
|
|
|
|
| |
*somewhere*; use MmapNoAccess in the Allocator when SpaceBeg is not a constant. In this mode the allocator will be a bit more hardened
llvm-svn: 267256
|
|
|
|
| |
llvm-svn: 267253
|
|
|
|
|
|
| |
use a non-fixed address range. An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point.
llvm-svn: 267252
|
|
|
|
| |
llvm-svn: 267251
|
|
|
|
|
|
| |
r267094 that has been reverted
llvm-svn: 267203
|
|
|
|
|
|
| |
This reverts commit r266716, as it breaks the self-hosting on Thumb2 buildbot.
llvm-svn: 267158
|
|
|
|
|
|
|
|
|
| |
range. An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point."
This reverts commit r267094, because it broke a lot of MSAN tests in AArch64.
Being NFC and all, this needs some deeper investigation before it goes in again.
llvm-svn: 267136
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When using 32-bit python with 64-bit asan the pc array in sancov.py cannot fit in 64-bit pc's because the type-code 'L' for
arrays in python corresponds to the C type long which is only of 4 bytes. Because of this some of the coverage tool tests fail on
mips. To fix these test possible solutions are to use 64-bit python or use struct.unpack with the 'Q' type-code. We have used
struct.unpack with 'Q' type code since it is not appropriate to have a 64-bit python on all hosts.
Reviewed by kcc, aizatsky
Differential: http://reviews.llvm.org/D18817
llvm-svn: 267126
|
|
|
|
|
|
| |
An allocator with a non-fixed address range will be attack-resistan. NFC for the sanitizers at this point.
llvm-svn: 267094
|
|
|
|
|
|
|
|
| |
Let's use pthread_threadid_np which returns a more reasonable ID than pthread_self (which is actually a stack pointer). The numbers from pthread_threadid_np are already used in other tools, e.g. in LLDB, and often appear in logs, so it's much more useful than pthread_self.
Differential Revision: http://reviews.llvm.org/D18951
llvm-svn: 266991
|
|
|
|
| |
llvm-svn: 266934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not sure what changed, but on my machine this is literally one byte
short. Only happens when malloc_context_size <= 2 due to the special
case in GET_STACK_TRACE definition (see asan_stack.h):
StackTrace::GetCurrentPc() on the right (context size > 2) branch
returns the address that is 200-something bytes from the return
address it is later matched to, while the same call on the left
branch is 321 bytes away from it.
This fixes the double-free test on my machine.
llvm-svn: 266932
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
old Darwin systems.
This patch fixes https://github.com/google/sanitizers/issues/669. On older Darwin systems (in particular, Darwin 10),
dyld doesn't export '_dyldVersionNumber' symbol so we would have 'undefined reference' error in sanitzer library. Although
sanitizers support was added to LLVM on OS X 10.7+ where '_dyldVersionNumber' symbol is already exported, GCC users still
may want use them on older systems.
Differential Revision: http://reviews.llvm.org/D19218
llvm-svn: 266868
|
|
|
|
|
|
|
|
|
| |
Summary: There is no frame validity check in the slow unwinder like there is in the fast unwinder due to which lsan reports a leak even for heap allocated coroutine in the test swapcontext.cc. Since mips/linux uses slow unwindwer instead of fast unwinder, the test fails for mips/linux. Therefore adding the checks before unwinding fixes the test for mips/linux.
Reviewers: samsonov, earthdok, kcc
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D18690
llvm-svn: 266716
|
|
|
|
|
|
|
| |
The test is failing on Windows because we do not have a definition for
DemangleSwiftAndCXX nor DemangleCXXABI, which I am replacing, on Windows.
llvm-svn: 266499
|
|
|
|
| |
llvm-svn: 266497
|
|
|
|
|
|
|
|
|
| |
Add support for Swift names when symbolicating sanitizer traces. This is
now relevant since TSan and ASan support have been added to Swift on OS X.
Differential Revision: http://reviews.llvm.org/D19135
llvm-svn: 266494
|
|
|
|
|
|
|
|
|
| |
This file will contain s390-specific code. For now, let's move the s390
version of internal_mmap here.
Differential Revision: http://reviews.llvm.org/D19174
llvm-svn: 266482
|
|
|
|
|
|
|
|
| |
CVE-2016-2143."
This reverts commit r266297.
llvm-svn: 266470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On s390, the return address is in %r14, which is saved 14 words from
the frame pointer.
Unfortunately, there's no way to do a proper fast backtrace on SystemZ
with current LLVM - the saved %r15 in fixed-layout register save
area points to the containing frame itself, and not to the next one.
Likewise for %r11 - it's identical to %r15, unless alloca is used
(and even if it is, it's still useless). There's just no way to
determine frame size / next frame pointer. -mbackchain would fix that
(and make the current code just work), but that's not yet supported
in LLVM. We will thus need to XFAIL some asan tests
(Linux/stack-trace-dlclose.cc, deep_stack_uaf.cc).
Differential Revision: http://reviews.llvm.org/D18895
llvm-svn: 266371
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first part of upcoming asan support for s390 and s390x.
Note that there are bits for 31-bit support in this and subsequent
patches - while LLVM itself doesn't support it, gcc should be able
to make use of it just fine.
Differential Revision: http://reviews.llvm.org/D18888
llvm-svn: 266370
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PS_STRINGS constant can easily be incorrect with mismatched
kernel/userland - e.g. when building i386 sanitizers on FreeBSD/amd64
with -m32. The kern.ps_strings sysctl was introduced over 20 years ago
as the supported way to fetch the environment and argument string
addresses from the kernel, so the fallback is never used.
Differential Revision: http://reviews.llvm.org/D19027
llvm-svn: 266305
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In short, CVE-2016-2143 will crash the machine if a process uses both >4TB
virtual addresses and fork(). ASan, TSan, and MSan will, by necessity, map
a sizable chunk of virtual address space, which is much larger than 4TB.
Even worse, sanitizers will always use fork() for llvm-symbolizer when a bug
is detected. Disable all three by aborting on process initialization if
the running kernel version is not known to contain a fix.
Unfortunately, there's no reliable way to detect the fix without crashing
the kernel. So, we rely on whitelisting - I've included a list of upstream
kernel versions that will work. In case someone uses a distribution kernel
or applied the fix themselves, an override switch is also included.
Differential Revision: http://reviews.llvm.org/D18915
llvm-svn: 266297
|
|
|
|
|
|
|
|
|
| |
This teaches sanitizer_common about s390 and s390x virtual space size.
s390 is unusual in that it has 31-bit virtual space.
Differential Revision: http://reviews.llvm.org/D18896
llvm-svn: 266296
|
|
|
|
|
|
|
|
|
|
| |
mmap on s390 is quite a special snowflake: since it has too many
parameters to pass them in registers, it passes a pointer to a struct
with all the parameters instead.
Differential Revision: http://reviews.llvm.org/D18889
llvm-svn: 266295
|
|
|
|
|
|
|
|
|
|
|
| |
Some bots failed with:
sanitizer_quarantine.h:104:7: error: unused typedef 'assertion_failed__104' [-Werror,-Wunused-local-typedef]
COMPILER_CHECK(kPrefetch <= ARRAY_SIZE(b->batch));
Replace COMPILER_CHECK with CHECK.
llvm-svn: 266291
|
|
|
|
| |
llvm-svn: 266288
|
|
|
|
|
|
|
|
| |
In `AtosSymbolizer`, we're using `forkpty()` to create a new pseudo-terminal to communicate with the `atos` tool (we need that to avoid output buffering in interactive mode). This however redirects both stdout and stderr into a single stream, so when we read the output, we can't distinguish between errors and standard replies. Let's save&restore stderr to avoid that.
Differential Revision: http://reviews.llvm.org/D15073
llvm-svn: 265923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The strlen interceptor is sometimes invoked too early for REAL(strlen) to
be initialized. A special check is added to use internal_strlen for this
situation.
Reviewers: dim
Subscribers: llvm-commits, samsonov
Differential Revision: http://reviews.llvm.org/D18851
Change-Id: I3acc58f4abbae1904f25324abd84efea67aad0a2
llvm-svn: 265705
|
|
|
|
| |
llvm-svn: 265269
|
|
|
|
|
|
|
| |
Move ifdefs to avoid unused static helpers. Move alignment attribute so
that it is respected in GCC and MSVC.
llvm-svn: 265153
|
|
|
|
| |
llvm-svn: 265152
|