mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "LeMay, Michael" <michael.lemay@intel.com>
To: musl@lists.openwall.com, LeMay@port70.net
Subject: Re: [RFC] Support for segmentation-hardened SafeStack
Date: Mon, 26 Sep 2016 10:55:16 -0700	[thread overview]
Message-ID: <eb8a4689-b594-e817-a8a1-a2ddb309d790@intel.com> (raw)
In-Reply-To: <20160923102202.GB1280@port70.net>



On 9/23/2016 03:22, Szabolcs Nagy wrote:
> * LeMay, Michael <michael.lemay@intel.com> [2016-09-22 23:00:45 +0000]:
>> I submitted several patches to LLVM and Clang to harden SafeStack using segmentation on x86-32 [1].  See [2] for general background on SafeStack.
> ...
>> [1] http://lists.llvm.org/pipermail/llvm-dev/2016-May/100346.html
>> [2] http://clang.llvm.org/docs/SafeStack.html
> is all runtime support in the libc with your patches?
> (i.e. no static linked interposition code from compiler-rt)

For programs linked against my patched version of musl with 
segmentation-hardened SafeStack enabled, the SafeStack library in 
compiler-rt is not needed.

>
> can you call into non-instrumented code?
> (as Rich noted this looks like a new abi on i386)
> i assume the segmented variant breaks abi while the
> non-segmented one does not.

Restricting segment limits does introduce additional considerations that 
are not applicable to the original version of SafeStack, as I described 
in the reply to Rich that I just sent.

>
> what is the unsafe stack size of the main thread?
> how much is the resource usage overhead?

I arbitrarily chose to allocate a main-thread unsafe stack that is twice 
as large as the main-thread safe stack.  The unsafe stack sizes for new 
threads are computed similarly to the safe stack sizes.  I'll post the 
current revision of my patches soon for the sake of discussion.

>
> what happens if unsafe stack allocation fails?

A limitation of my current patches is that there is no support for 
dynamically expanding the size of the unsafe stack.  By the way, I think 
that this is also a limitation of the current compiler-rt support for 
the original version of SafeStack.

> how does the stack get deallocated at thread exit?
> i assume they are consistent with normal stack
> handling if this is done in musl.. except for the
> main thread.

Yes, the unsafe stack gets deallocated when non-main threads exit.

>
> can signal handlers work with sigaltstack?

That's an interesting question.  One thing to consider is that the 
kernel will only switch the safe stack when sigaltstack is used, not the 
unsafe stack.  Furthermore, for the segmentation-based hardening to 
apply to the stack passed to sigaltstack, that stack would need to be 
allocated above the restricted limits of DS and ES.

Thanks,
Michael



      reply	other threads:[~2016-09-26 17:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 23:00 LeMay, Michael
2016-09-22 23:42 ` Rich Felker
2016-09-26 17:28   ` LeMay, Michael
2016-09-26 18:08     ` Rich Felker
2016-09-27  6:05       ` LeMay, Michael
2016-09-27 14:43         ` Rich Felker
2016-09-27 21:35           ` LeMay, Michael
2016-09-23 10:22 ` Szabolcs Nagy
2016-09-26 17:55   ` LeMay, Michael [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb8a4689-b594-e817-a8a1-a2ddb309d790@intel.com \
    --to=michael.lemay@intel.com \
    --cc=LeMay@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).