From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10710 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC PATCH v3 0/2] SafeStack support Date: Sat, 5 Nov 2016 23:57:10 +0100 Message-ID: <20161105225710.GL5749@port70.net> References: <390CE752059EB848A71F4F676EBAB76D3AC2987A@ORSMSX114.amr.corp.intel.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1478386664 7031 195.159.176.226 (5 Nov 2016 22:57:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Nov 2016 22:57:44 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: LeMay@port70.net, Michael To: musl@lists.openwall.com Original-X-From: musl-return-10723-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 05 23:57:39 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 1c39tp-0007uv-BL for gllmg-musl@m.gmane.org; Sat, 05 Nov 2016 23:57:21 +0100 Original-Received: (qmail 32047 invoked by uid 550); 5 Nov 2016 22:57:22 -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 32024 invoked from network); 5 Nov 2016 22:57:22 -0000 Mail-Followup-To: musl@lists.openwall.com, LeMay@port70.net, Michael Content-Disposition: inline In-Reply-To: <390CE752059EB848A71F4F676EBAB76D3AC2987A@ORSMSX114.amr.corp.intel.com> Xref: news.gmane.org gmane.linux.lib.musl.general:10710 Archived-At: * 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 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.