From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13464 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Wed, 21 Nov 2018 15:46:52 +0100 Message-ID: <20181121144652.GM21289@port70.net> References: 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 1542811500 24432 195.159.176.226 (21 Nov 2018 14:45:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 14:45:00 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Gernot Reisinger To: musl@lists.openwall.com Original-X-From: musl-return-13480-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 15:44:55 2018 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 1gPTkN-0006GA-9J for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 15:44:55 +0100 Original-Received: (qmail 3270 invoked by uid 550); 21 Nov 2018 14:47:04 -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 3252 invoked from network); 21 Nov 2018 14:47:03 -0000 Mail-Followup-To: musl@lists.openwall.com, Gernot Reisinger Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13464 Archived-At: * Gernot Reisinger [2018-11-21 14:55:19 +0100]: > Hi, > I recently stumbled upon an issue with preloading a shared object into a Go > application (see related Go ticket https://github.com/golang/go/issues/28909 > ). > > In short - Go comes with an internal linker which will not link crt code to > the application. The entry point will directly execute Go standard library then calling into the c runtime later is undefined. crt is required for the c runtime setup. > code. As musl libc calls shared object constructors in crt code, the shared this is not true, the crt code is a tiny stub that calls the __libc_start_main setup code in libc.so, where ctors are run (there are several mechanisms to do ctors, but that's an elf thing: musl supports both _init and initarry style initializers, former is passed as argument to __libc_start_main the latter requires begin/end symbols for the .initarray section, in glibc is similar, but part of the initialization happens in the dynamic linker and part of it in libc_nonshared.a code which should be linked to the application and not in libc.so. static linking is another story but i assume you are using dynamic linking). > objects constructors subsequently will never be invoked. Things will work > on glibc systems / processes. it It seems to be a subtle - but in this case > wide reaching - behavioral difference to glibc. this is libc internal implementation detail that callers should not try to guess or rely on. (however it has to be abi stable within one libc implementation because old crt1.o linked into an executable must work with new libc.so, otoh in glibc the abi can changed over time using symbol versioning for backward compatibility, and there were talks about doing exactly that because the way it runs ctor code is a perfect gadget for rop attacks and present in every executable) > I wonder if calling constructor functions from crt code is an intended musl > libc behavior. My personal - non expert - gut feeling considers glibc > behavior "more correct". Is there a chance that musl will change this what made you think musl calls ctors from crt code? > behavior? > br > Gernot