From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6231 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: A running list of questions from "porting" Slackware to musl Date: Wed, 1 Oct 2014 09:29:32 -0400 Message-ID: <20141001132932.GJ23797@brightrain.aerifal.cx> References: <542AA579.2040304@langurwallah.org> <20140930153216.GA1785@newbook> <20140930155023.GC23797@brightrain.aerifal.cx> <542B41C4.1040701@amacapital.net> <20141001000516.GI23797@brightrain.aerifal.cx> <542B95DB.7050209@mit.edu> 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 1412170194 22431 80.91.229.3 (1 Oct 2014 13:29:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 13:29:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6244-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 01 15:29:47 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 1XZJyU-0005hs-Ji for gllmg-musl@plane.gmane.org; Wed, 01 Oct 2014 15:29:46 +0200 Original-Received: (qmail 24550 invoked by uid 550); 1 Oct 2014 13:29:45 -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 24539 invoked from network); 1 Oct 2014 13:29:45 -0000 Content-Disposition: inline In-Reply-To: <542B95DB.7050209@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6231 Archived-At: On Tue, Sep 30, 2014 at 10:49:15PM -0700, Andy Lutomirski wrote: > >>(Even better: the loader could patch the PLT with a direct jump. Could > >>musl do this? At least in the case where the symbol is within 2G of the > >>PLT entry, > > > >This is really not a good idea. The old PowerPC ABI did this, and musl > >does not support it (it requires the new "secure-plt" mode). Hardened > >kernels have various restrictions on modifying executable pages, up to > >and including completely forbidding this kind of usage. And even if > >it's not forbidden, it's going to use more memory due to an additional > >page (or more) per shared library that's not going to be sharable. > >Also it requires complex per-arch code (minimal machine code > >generation, instruction cache flushing/barriers, etc.). > > That extra page might not be needed if the linker could end up > removing a bunch of GOT entries for functions that don't have their > addresses taken. (Or, on x86_64, where unaligned access is cheap, > the GOT could actually overlap the PLT in memory, but only if This is not an option. It would require the page containing the GOT (and a lot of data) to be executable. Not only is this a huge security risk (makes exploiting other vulnerabilities a lot easier); it's also physically impossible to do on hardened kernels which simply lack "rwx" permission for mappings. > >>this should be straightforward if no threads have been > >>started yet. > > > >Threads having been started or not are not relevant. The newly loaded > >code is not visible until dlopen returns, so nothing can race with > >modifications to it. > > True, at least when lazy binding is off. musl does not do lazy binding at all, and won't. There's been some demand for it in terms of allowing loading hacks where the symbols needed by the loaded library are not provided until later, but that can be satisfied by emulating it (basically, keeping a list of unsatisfied relocs and retrying them after each dlopen) rather than actually doing lazy binding at call time. Rich