* [RFC PATCH v3 0/2] SafeStack support
@ 2016-11-04 20:31 LeMay, Michael
2016-11-05 22:57 ` Szabolcs Nagy
0 siblings, 1 reply; 2+ messages in thread
From: LeMay, Michael @ 2016-11-04 20:31 UTC (permalink / raw)
To: musl
This first patchset adds architecture-independent support for SafeStack. A separate patch adds support for segmentation-based SafeStack hardening.
v2 -> v3:
- Further coalesced patches as they have become smaller and simpler.
- Reduced the use of ifdefs.
- Used musl-controlled macro in pthread_impl.h.
- Revised definition of preinit_us.
- Added __safestack_pthread_exit.
- Fixed invalid preprocessor expression in traverses_stack_p.
- Passed updated stack pointer to __clone during thread creation.
- Updated __stack_base in __safestack_init_thread.
- Simplified __sep_stack_seg_init and subroutines by requiring that LDT is empty prior to initialization.
Michael LeMay (2):
support SafeStack
add SafeStack build support
Makefile | 51 +++++++++++++++++-
configure | 10 ++++
ldso/dynlink.c | 13 +++++
src/env/__libc_start_main.c | 5 ++
src/internal/pthread_impl.h | 13 +++++
src/internal/safe_stack.c | 128 ++++++++++++++++++++++++++++++++++++++++++++
src/malloc/expand_heap.c | 2 +
src/thread/pthread_create.c | 14 ++++-
8 files changed, 234 insertions(+), 2 deletions(-)
create mode 100644 src/internal/safe_stack.c
--
2.7.4
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC PATCH v3 0/2] SafeStack support
2016-11-04 20:31 [RFC PATCH v3 0/2] SafeStack support LeMay, Michael
@ 2016-11-05 22:57 ` Szabolcs Nagy
0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2016-11-05 22:57 UTC (permalink / raw)
To: musl; +Cc: LeMay, Michael
* LeMay, Michael <michael.lemay@intel.com> [2016-11-04 20:31:57 +0000]:
> This first patchset adds architecture-independent support for SafeStack. A separate patch adds support for segmentation-based SafeStack hardening.
>
general observations before i forget them:
- musl does not have optional runtime features yet, this means
existing libc binaries have consistent behaviour and testing
is simpler. (we might need some solution for experimental
runtime features)
- safestack implies 2x stack size increasing resource usage
significantly.
- safestack needs an upper bound on the main thread stack size,
this can be slow to compute and might not be a tight bound
causing significant startup latency and resource use.
- if such costs affect processes that don't use safe-stack
then it cannot be an unconditional feature of libc.
(however with tagging the elf modules that use safe-stack
it may be possible to allocate the unsafe stacks in a lazy
way, only if any of the loaded modules need it, assuming
the libc itself is non-instrumented).
- user allocated stacks may have special properties (e.g.
allocated in shared memory) that the unsafe stack won't
have (and that's where stack objects live to which
pointers are passed around so this has observable effects,
matters for pthread and sigalt stacks as well).
- sigaltstack size cannot be accounted for in the unsafe
stack of each thread, so signal handlers which might run
on an alt stack can overflow the unsafe stack (in the libc
this means that as-safe apis must not be safe-stack
instrumented, but i don't see an easy way to fix this for
user code: wrapping signal handlers and setting up an unsafe
stack there may work but very ugly).
- in principle a hardening solution should not break conforming
code, but if at least the runtime support does not affect
processes that don't use it, then i think adding the support
is acceptable. (in practice i think thread stack issues
are more problematic than signal stack ones: signal handlers
rarely call across library boundaries, but for threads an
instrumented library can easily break an uninstrumented
caller, so distributing instrumented libraries can break things).
- the abi between the compiler and libc is a nasty one (like
the ssp canary): such hard coded tcb offsets are usually not
documented in any abi spec and may conflict with c runtime
implementation internals (in case of safestack the offsets
are somehow already inconsistent on 32bit vs 64bit targets).
ideally there would be a tls abi spec with some reserved
tls space which can be publicly assigned to implementations
such as safestack.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-11-05 22:57 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-04 20:31 [RFC PATCH v3 0/2] SafeStack support LeMay, Michael
2016-11-05 22:57 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).