Checking the OS version via `GetMacosAlignedVersion()` now works in
simulators [1]. Let's use it to simplify `DyldNeedsEnvVariable()`.
[1] 3fb0de8207
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D81197
compiler-rt checks OS versions by querying the Darwin kernel version.
This is not necessarily correct inside the simulators if the simulator
runtime is not aligned with the host macOS. Let's instead check the
`SIMULATOR_RUNTIME_VERSION` env var.
rdar://63031937
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D83977
For now, xdrrec_create is only intercepted Linux as its signature
is different on Solaris.
The method of intercepting xdrrec_create isn't super ideal but I
couldn't think of a way around it: Using an AddrHashMap combined
with wrapping the userdata field.
We can't just allocate a handle on the heap in xdrrec_create and leave
it at that, since there'd be no way to free it later. This is because it
doesn't seem to be possible to access handle from the XDR struct, which
is the only argument to xdr_destroy.
On the other hand, the callbacks don't have a way to get at the
x_private field of XDR, which is what I chose for the HashMap key. So we
need to wrap the handle parameter of the callbacks. But we can't just
pass x_private as handle (as it hasn't been set yet). We can't put the
wrapper struct into the HashMap and pass its pointer as handle, as the
key we need (x_private again) hasn't been set yet.
So I allocate the wrapper struct on the heap, pass its pointer as
handle, and put it into the HashMap so xdr_destroy can find it later and
destroy it.
Differential Revision: https://reviews.llvm.org/D83358
- there are additional fields for glob_t struct, thus size check is failing.
- to access old mman.h api based on caddr_t, _XOPEN_SOURCE needs to be not defined
thus we provide the prototype.
- prxmap_t constified.
Reviewers: ro, eugenis
Reviewed-By: ro
Differential Revision: https://reviews.llvm.org/D84046
Summary:
It turns out the `CHECK(addr >= reinterpret_cast<upt>(info.dli_saddr)`
can fail because on armv7s on iOS 9.3 `dladdr()` returns
`info.dli_saddr` with an address larger than the address we provided.
We should avoid crashing here because crashing in the middle of reporting
an issue is very unhelpful. Instead we now try to compute a function offset
if the value we get back from `dladdr()` looks sane, otherwise we don't
set the function offset.
A test case is included. It's basically a slightly modified version of
the existing `test/sanitizer_common/TestCases/Darwin/symbolizer-function-offset-dladdr.cpp`
test case that doesn't run on iOS devices right now.
More details:
In the concrete scenario on armv7s `addr` is `0x2195c870` and the returned
`info.dli_saddr` is `0x2195c871`.
This what LLDB says when disassembling the code.
```
(lldb) dis -a 0x2195c870
libdyld.dylib`<redacted>:
0x2195c870 <+0>: nop
0x2195c872 <+2>: blx 0x2195c91c ; symbol stub for: exit
0x2195c876 <+6>: trap
```
The value returned by `dladdr()` doesn't make sense because it points
into the middle of a instruction.
There might also be other bugs lurking here because I noticed that the PCs we
gather during stackunwinding (before changing them with
`StackTrace::GetPreviousInstructionPc()`) look a little suspicious (e.g. the
PC stored for the frame with fail to symbolicate is 0x2195c873) as they don't
look properly aligned. This probably warrants further investigation in the future.
rdar://problem/65621511
Reviewers: kubamracek, yln
Subscribers: kristof.beyls, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D84262
Fix build failure in Fuchsia build from refactoring in
5d2be1a188
Guard the moved versions of ReserveShadowMemoryRange and ProtectGap
the same way they were in the asan code originally (not for Fuchsia or
RTEMS). Otherwise we end up with unsats as they invoke functions not
defined there.
Fix failure in Android bots from refactoring in
5d2be1a188 (https://crbug.com/1106482).
We need to make the UnmapFromTo available outside sanitizer_common for
calls from hwasan and asan linux handling. While here, remove
declaration of GetHighMemEnd which is no longer in sanitizer_common.
Summary:
This refactors some common support related to shadow memory setup from
asan and hwasan into sanitizer_common. This should not only reduce code
duplication but also make these facilities available for new compiler-rt
uses (e.g. heap profiling).
In most cases the separate copies of the code were either identical, or
at least functionally identical. A few notes:
In ProtectGap, the asan version checked the address against an upper
bound (kZeroBaseMaxShadowStart, which is (2^18). I have created a copy
of kZeroBaseMaxShadowStart in hwasan_mapping.h, with the same value, as
it isn't clear why that code should not do the same check. If it
shouldn't, I can remove this and guard this check so that it only
happens for asan.
In asan's InitializeShadowMemory, in the dynamic shadow case it was
setting __asan_shadow_memory_dynamic_address to 0 (which then sets both
macro SHADOW_OFFSET as well as macro kLowShadowBeg to 0) before calling
FindDynamicShadowStart(). AFAICT this is only needed because
FindDynamicShadowStart utilizes kHighShadowEnd to
get the shadow size, and kHighShadowEnd is a macro invoking
MEM_TO_SHADOW(kHighMemEnd) which in turn invokes:
(((kHighMemEnd) >> SHADOW_SCALE) + (SHADOW_OFFSET))
I.e. it computes the shadow space needed by kHighMemEnd (the shift), and
adds the offset. Since we only want the shadow space here, the earlier
setting of SHADOW_OFFSET to 0 via __asan_shadow_memory_dynamic_address
accomplishes this. In the hwasan version, it simply gets the shadow
space via "MemToShadowSize(kHighMemEnd)", where MemToShadowSize just
does the shift. I've simplified the asan handling to do the same
thing, and therefore was able to remove the setting of the SHADOW_OFFSET
via __asan_shadow_memory_dynamic_address to 0.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: dberris, #sanitizers, llvm-commits, davidxl
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D83247
compiler-rt checks OS versions by querying the Darwin kernel version.
This is not necessarily correct inside the simulators if the simulator
runtime is not aligned with the host macOS. Let's instead check the
`SIMULATOR_RUNTIME_VERSION` env var.
Note that we still use the old code path as a fallback in case the
`SIMULATOR_RUNTIME_VERSION` environment variable isn't set.
rdar://63031937
Reviewers: delcypher
Differential Revision: https://reviews.llvm.org/D79979
A dozen 32-bit `AddressSanitizer` testcases FAIL on the latest beta of Solaris 11.4/x86, e.g.
`AddressSanitizer-i386-sunos :: TestCases/null_deref.cpp` produces
AddressSanitizer:DEADLYSIGNAL
=================================================================
==29274==ERROR: AddressSanitizer: stack-overflow on address 0x00000028 (pc 0x08135efd bp 0xfeffdfd8 sp 0x00000000 T0)
#0 0x8135efd in NullDeref(int*) /vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10
#1 0x8135ea6 in main /vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/null_deref.cpp:21:3
#2 0x8084b85 in _start (null_deref.cpp.tmp+0x8084b85)
SUMMARY: AddressSanitizer: stack-overflow /vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10 in NullDeref(int*)
==29274==ABORTING
instead of the expected
AddressSanitizer:DEADLYSIGNAL
=================================================================
==29276==ERROR: AddressSanitizer: SEGV on unknown address 0x00000028 (pc 0x08135f1f bp 0xfeffdf48 sp 0xfeffdf40 T0)
==29276==The signal is caused by a WRITE memory access.
==29276==Hint: address points to the zero page.
#0 0x8135f1f in NullDeref(int*) /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10
#1 0x8135efa in main /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/null_deref.cpp:21:3
#2 0x8084be5 in _start (null_deref.cpp.tmp+0x8084be5)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10 in NullDeref(int*)
==29276==ABORTING
I managed to trace this to a change in `<sys/regset.h>`: previously the header would
primarily define the short register indices (like `UESP`). While they are required by the
i386 psABI, they are only required in `<ucontext.h>` and could previously leak into
unsuspecting user code, polluting the namespace and requiring elaborate workarounds
like that in `llvm/include/llvm/Support/Solaris/sys/regset.h`. The change fixed that by restricting
the definition of the short forms appropriately, at the same time defining all `REG_` prefixed
forms for compatiblity with other systems. This exposed a bug in `compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp`, however:
Previously, the index for the user stack pointer would be hardcoded if `REG_ESP`
wasn't defined. Now with that definition present, it turned out that `REG_ESP` was the wrong index to use: the previous value 17 (and `REG_SP`) corresponds to `REG_UESP`
instead.
With that change, the failures are all gone.
Tested on `amd-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D83664
Support macOS 11 in our runtime version checking code and update
`GetMacosAlignedVersionInternal()` accordingly. This follows the
implementation of `Triple::getMacOSXVersion()` in the Clang driver.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D82918
This also allows intercepting these getprotoent functions on Linux as
well, since Linux exposes them.
Differential Revision: https://reviews.llvm.org/D82424
Summary:
28c91219c7 introduced an interceptor for `sigaltstack`. It turns out this
broke `setjmp` on i386 macOS. This is because the implementation of `setjmp` on
i386 macOS is written in assembly and makes the assumption that the call to
`sigaltstack` does not clobber any registers. Presumably that assumption was
made because it's a system call. In particular `setjmp` assumes that before
and after the call that `%ecx` will contain a pointer the `jmp_buf`. The
current interceptor breaks this assumption because it's written in C++ and
`%ecx` is not a callee-saved register. This could be fixed by writing a
trampoline interceptor to the existing interceptor in assembly that
ensures all the registers are preserved. However, this is a lot of work
for very little gain. Instead this patch just disables the interceptor
on i386 macOS.
For other Darwin architectures it currently appears to be safe to intercept
`sigaltstack` using the current implementation because:
* `setjmp` for x86_64 saves the pointer `jmp_buf` to the stack before calling `sigaltstack`.
* `setjmp` for armv7/arm64/arm64_32/arm64e appears to not call `sigaltstack` at all.
This patch should unbreak (once they are re-enabled) the following
tests:
```
AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.LongJmpTest
AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.SigLongJmpTest
AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.LongJmpTest
AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.SigLongJmpTest
AddressSanitizer-i386-darwin :: TestCases/longjmp.cpp
```
This patch introduces a `SANITIZER_I386` macro for convenience.
rdar://problem/62141412
Reviewers: kubamracek, yln, eugenis
Subscribers: kristof.beyls, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D82691
The Swift symbol name prefix has changed from `_T0` to `_$s` as
documented here [1]. This prevents Swift names from properly being
symbolicated when using the in-process LLVM symbolizer. The best way to
fix this seems to be to avoid the duplication of "Is this a Swift symbol
name?" here. We can simply remove this check as `swift_demangle`
already returns null for non-Swift names [2,3].
The check was included in the initial support for Swift name demangling
to avoid superfluous calls to `dlsym()` [4]. A subsequent commit
changed this logic to retrieve the `swift_demangle` function pointer
eagerly during sanitizer initialization, but did not remove the check
[5].
[1] https://github.com/apple/swift/blob/master/docs/ABI/Mangling.rst
[2] b5a8b518ea/include/swift/Demangling/Demangle.h (L643)
[3] b5a8b518ea/stdlib/public/runtime/Demangle.cpp (L656)
[4] https://reviews.llvm.org/D19135
[5] https://reviews.llvm.org/D20015
rdar://62753845
Reviewers: kubamracek, delcypher, dcoughlin, samsonov, thakis
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D81705
Summary:
Currently, there is no way to let the `InternalSymbolizer` implemented
functions know if inline frames should be symbolized. This patch updates
the function `__sanitizer_symbolize_code` to include a parameter for
this ASAN option and toggle between LLVM symbolization functions when
appropriate.
Fixes the following two failing tests when internal symbolization is
enabled:
```
SanitizerCommon-*-x86_64-Linux :: print-stack-trace.cpp
SanitizerCommon-*-x86_64-Linux :: symbolize_pc_inline.cpp
```
Reviewers: vitalybuka, kcc, filcab
Reviewed By: vitalybuka
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79280
Summary: Refactor the current global header iteration to be callback-based, and add a feature that reports the size of the global variable during reporting. This allows binaries without symbols to still report the size of the global variable, which is always available in the HWASan globals PT_NOTE metadata.
Reviewers: eugenis, pcc
Reviewed By: pcc
Subscribers: mgorny, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D80599
Use a struct to represent numerical versions instead of encoding release
names in an enumeration. This avoids the need to extend the enumeration
every time there is a new release.
Rename `GetMacosVersion() -> GetMacosAlignedVersion()` to better reflect
how this is used on non-MacOS platforms.
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79970
Remove it from target-specific scope which corresponds
to sanitizer_linux.cpp where it lives in the same macro
scope.
Differential Revision: https://reviews.llvm.org/D80864
This applies the learnings from [1]. What I intended as a simple
cleanup made me realize that the compiler-rt version checks have two
separate issues:
1) In some places (e.g., mmap flag setting) what matters is the kernel
version, not the OS version.
2) OS version checks are implemented by querying the kernel version.
This is not necessarily correct inside the simulators if the
simulator runtime isn't aligned with the host macOS.
This commit tackles 1) by adopting a separate query function for the
Darwin kernel version. 2) (and cleanups) will be dealt with in
follow-ups.
[1] https://reviews.llvm.org/D78942
rdar://63031937
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79965
Julian Lettner