Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 5 Nov 2016 23:57:10 +0100
From: Szabolcs Nagy <>
Cc:, Michael <>
Subject: Re: [RFC PATCH v3 0/2] SafeStack support

* LeMay, Michael <> [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

- 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.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.