From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10522 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: Tue, 27 Sep 2016 14:35:33 -0700 Message-ID: <4b5d9700-1550-3276-65c4-bd3072db24f6@intel.com> References: <390CE752059EB848A71F4F676EBAB76D3AC0B184@ORSMSX114.amr.corp.intel.com> <20160922234219.GA19318@brightrain.aerifal.cx> <20160926180822.GD19318@brightrain.aerifal.cx> <64befac3-af89-611a-70d1-9838c91097b3@intel.com> <20160927144303.GG19318@brightrain.aerifal.cx> 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 1475012154 17127 195.159.176.226 (27 Sep 2016 21:35:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2016 21:35:54 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: "musl@lists.openwall.com" To: Rich Felker Original-X-From: musl-return-10535-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 27 23:35:50 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 1bp02V-0003cF-VO for gllmg-musl@m.gmane.org; Tue, 27 Sep 2016 23:35:48 +0200 Original-Received: (qmail 28114 invoked by uid 550); 27 Sep 2016 21:35:47 -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 28096 invoked from network); 27 Sep 2016 21:35:46 -0000 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,406,1470726000"; d="scan'208";a="1037321289" In-Reply-To: <20160927144303.GG19318@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10522 Archived-At: On 9/27/2016 07:43, Rich Felker wrote: > On Mon, Sep 26, 2016 at 11:05:06PM -0700, LeMay, Michael wrote: ... >> Arguments, whether variadic or not, are still passed on the main >> (safe) stack like usual, and they can be used in-place. > Here I think we're just differing on what "used in-place" means. For > me that would include the ability to take their addresses. I assume > you're just talking about using the values. I see your point now. Yes, when SafeStack determines that a local variable or argument may be accessed unsafely, it moves or copies (respectively) that allocation to the unsafe stack. Incidentally, I thought that just taking the address of a local variable or argument (e.g. for pointer comparisons within a single function) would not necessarily result in it being moved to the unsafe stack, but re-reading the SafeStack pass and running some tests showed me that the pass currently does move such allocations to the unsafe stack. ... > > This is another place where I think we're just using terms > differently. From my perspective (the formal C language) variadic > argument handling does not involve taking or dereferencing addresses > on the stack; those are just va_list/va_arg implementation details. At > the level of the formal language I think there are no exceptions; in > all cases where the address on "the stack" leaks outside the scope of > what the compiler can see/control, "the stack" it's on has to be the > unsafe stack. Yes, we're in agreement. For completeness, I'll note that there are other ways for safe stack pointers to leak: http://clang.llvm.org/docs/SafeStack.html#known-security-limitations Thanks, Michael