From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6219 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: A running list of questions from "porting" Slackware to musl Date: Tue, 30 Sep 2014 11:50:23 -0400 Message-ID: <20140930155023.GC23797@brightrain.aerifal.cx> References: <542AA579.2040304@langurwallah.org> <20140930153216.GA1785@newbook> 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 1412092244 26782 80.91.229.3 (30 Sep 2014 15:50:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 15:50:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6232-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 30 17:50:36 2014 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 1XYzhE-0002Z3-AM for gllmg-musl@plane.gmane.org; Tue, 30 Sep 2014 17:50:36 +0200 Original-Received: (qmail 7545 invoked by uid 550); 30 Sep 2014 15:50:35 -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 7537 invoked from network); 30 Sep 2014 15:50:35 -0000 Content-Disposition: inline In-Reply-To: <20140930153216.GA1785@newbook> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6219 Archived-At: On Tue, Sep 30, 2014 at 08:32:16AM -0700, Isaac Dunham wrote: > On Tue, Sep 30, 2014 at 06:13:37PM +0530, Weldon Goree wrote: > > Hi all, > > > > I added the quotation marks of shame because it's not a "port" in a real > > sense. But still: I've had this side project[1] for a while of porting > > Slackware to use Musl and it's Nearly There (tm), but I was hoping for some > > advice on some persistent irritations I have. (Sorry for the length.) > > > 6. Stack protection. This one really puzzles me. Stack protection is as > > alien to glibc as it is to musl, but I keep running into this. 90% of the > > problems can be avoided with adding -fno-stack-protector appropriately, but > > libtool is very "helpful" on matters like this and seems to find a way to > > put it back. I've actually not found an unworkable problem yet (though > > several very annoying ones); I guess I'm just curious what the real state of > > ssp on musl is (I'm not a fan of the concept, personally, but I know a lot > > of people are), and whether there's a general solution to just telling > > software to trust the ****ing stack. > > You need a "libssp_nonshared.a" containing a function named > __stack_chk_fail_local, which need only call __stack_chk_fail. > No idea why, but this cannot be in a shared libary. When gcc generates the canary-check code, on failure it normally calls/jumps to __stack_chk_fail. But for shared libraries, that call would go to a thunk in the library's PLT, which depends on the GOT register being initialized (actually this varies by arch; x86_64 doesn't need it). In order to avoid (expensive) loading of the GOT register in every function just as a contingency in case __stack_chk_fail needs to be called, for position-independent code GCC generates a call to __stack_chk_fail_local instead. This is a hidden function (and necessarily exists within the same .so) so the call doesn't have to go through the PLT; it's just a straight relative call/jump instruction. __stack_chk_fail_local is then responsible for loading the GOT register and calling __stack_chk_fail. Rich