From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4139 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: -fno-stack-protector and musl Date: Mon, 21 Oct 2013 11:32:04 -0400 Message-ID: <20131021153203.GR20515@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1382369534 9623 80.91.229.3 (21 Oct 2013 15:32:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2013 15:32:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4143-gllmg-musl=m.gmane.org@lists.openwall.com Mon Oct 21 17:32:17 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VYHSq-0008DR-Vj for gllmg-musl@plane.gmane.org; Mon, 21 Oct 2013 17:32:17 +0200 Original-Received: (qmail 23557 invoked by uid 550); 21 Oct 2013 15:32:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22525 invoked from network); 21 Oct 2013 15:32:16 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4139 Archived-At: On Mon, Oct 21, 2013 at 11:20:06PM +0800, Christopher Meng wrote: > Hi all, > > I'm going to package this c lib into Fedora for skalibs. However > Fedora forces us to package every pkg with optflags inserted: I can assure you glibc is not compiled with stack protector either, so there are exceptions to this policy. :) You should just cite such an exception. It's my long-term goal to support compiling musl itself with stack protector, but this is dependent on groundwork in two areas: 1. There needs to be a way to force stack protector off in at least a few files which are needed for early initialization, before the canary is available. This needs build system support and call tree analysis of what files need such special handling. 2. Since the canary is stored at a fixed offset from the thread pointer, the thread pointer must always be initialized when ssp is used. This is handled correctly now (modulo one gcc bug) for apps and libs that use ssp, but not for libc-internal use. In the 1.1 series I plan to make the thread pointer always-initialized. I expect the resolution of this issue somewhere in the early to mid 1.1 series. For what it's worth, we're no worse than glibc in this regard right now, and hope to be better in the future. Rich