This lets us do two things:
1) Make setjmp and longjmp compatible with shadow call stack.
To avoid leaking the shadow call stack address into memory, only the
lower log2(SCS_SIZE) bits of x18 are stored to jmp_buf. This requires
allocating an additional guard page so that we're guaranteed to be
able to allocate a sufficiently aligned SCS.
2) SCS overflow detection. Overflows now result in a SIGSEGV instead
of corrupting the allocation that comes after it.
Change-Id: I04d6634f96162bf625684672a87fba8b402b7fd1
Test: bionic-unit-tests
Previously, we were zeroing out the reserved signals, when we actually
wanted to have TIMER_SIGNAL always be blocked, and the other signals
always be unblocked. This resulted in process termination when a
SIGEV_THREAD timer callback calls sigprocmask(SIG_SETMASK, ...) with
any signal mask value, and then subsequently fails to complete its
callback and reach the sigtimedwait in bionic before the next timer
iteration triggers.
Add a how argument to filter_reserved_signals to appropriately
block/unblock our reserved signals.
Bug: http://b/116783733
Test: bionic-unit-tests32/64
Change-Id: Ie5339682cdeb914711cd4089cd26ee395704d0df
We saw crashes from pthread_exit+debuggerd on LP32
(https://issuetracker.google.com/72291624), and it seems like the
equivalent problem should exist with system(3). I fixed posix_spawn(3)
as part of that bug, so the easiest fix is probably to reuse that.
Bug: http://b/72470344
Test: ran tests
Change-Id: I05f838706f2b4a14ac3ee21292833e6c8579b0d4
Our arm and x86 ABIs shipped with a 32-bit `sigset_t`, so we need to
use sigprocmask64 to save/restore the RT signals too. (This is important
because several are in use by the system, and the behavior of our 32-bit
`sigset_t` is to clear the RT signals.)
Bug: http://b/72493232
Test: ran tests
Change-Id: Idff91f8b2849276e5a3073d07eccd84e02a34410
Make it easier to diagnose applications mucking with the contents of
jmp_buf by checksumming its contents.
Bug: http://b/27417786
Change-Id: I473bc2871dece23a9b9d02481945246160d671c6
Make it easier to diagnose applications mucking with the contents of
jmp_buf by checksumming its contents.
Bug: http://b/27417786
Change-Id: I9989e2ea3979a36ae0bc4c9e1bacafddbacc731b
Reuse the top bits of _JB_SIGFLAG field previously used to store a
boolean to store a cookie that's validated by [sig]longjmp to make it
harder to use as a ROP gadget. Additionally, encrypt saved registers
with the cookie so that an attacker can't modify a register's value to
a specific value without knowing the cookie.
Bug: http://b/23942752
Change-Id: Id0eb8d06916e89d5d776bfcaa9458f8826717ba3
Although the LP32 mips sigset_t is large enough to represent all signals,
their jmp_buf is too small. This test succeeded on arm and x86 because the
RT signals were never in the 'expected' sigset_t, so the equality comparison
with the 'actual' sigset_t worked fine --- everyone was blind to the RT
signal. On mips the tests fail because the 'expected' sigset_t does contain
the RT signal but the 'actual' doesn't because the jmp_buf only saves and
restores the first 32 signals.
There are 32 free bits (currently used as padding) in the LP32 mips jmp_buf,
and they might choose to use those to provide better support than the other
two platforms, but I'll leave that to them. It will be easy to just remove
the #if defined(__LP64__) from this change in that case.
For mips64 it's not to late to increase the size of the jmp_buf and fix
the setjmp family, but since there are decisions to be made here for LP32,
I'll leave it all to Imagination folks...
Bug: 16918359
Change-Id: I6b723712fce0e9210dafa165d8599d950b2d3500
