From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10518 Path: news.gmane.org!.POSTED!not-for-mail From: "LeMay, Michael" Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC] Support for segmentation-hardened SafeStack Date: Mon, 26 Sep 2016 10:55:16 -0700 Message-ID: References: <390CE752059EB848A71F4F676EBAB76D3AC0B184@ORSMSX114.amr.corp.intel.com> <20160923102202.GB1280@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1474912557 13172 195.159.176.226 (26 Sep 2016 17:55:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Sep 2016 17:55:57 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 To: musl@lists.openwall.com, LeMay@port70.net Original-X-From: musl-return-10531-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 26 19:55:53 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1boa7l-0000LA-KB for gllmg-musl@m.gmane.org; Mon, 26 Sep 2016 19:55:29 +0200 Original-Received: (qmail 17842 invoked by uid 550); 26 Sep 2016 17:55:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17824 invoked from network); 26 Sep 2016 17:55:29 -0000 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,400,1470726000"; d="scan'208";a="1036731278" In-Reply-To: <20160923102202.GB1280@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:10518 Archived-At: On 9/23/2016 03:22, Szabolcs Nagy wrote: > * LeMay, Michael [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