From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112480 invoked by alias); 22 Mar 2018 09:28:14 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 82650 invoked by uid 89); 22 Mar 2018 09:27:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*F:U*fw X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: albireo.enyo.de Received: from albireo.enyo.de (HELO albireo.enyo.de) (5.158.152.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 09:27:45 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1eywVY-0004cm-Q5; Thu, 22 Mar 2018 09:27:40 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1eyw4c-0003NY-Un; Thu, 22 Mar 2018 09:59:50 +0100 From: Florian Weimer To: Carlos O'Donell Cc: "H.J. Lu" , Generic System V Application Binary Interface , gnu-gabi@sourceware.org Subject: Re: RFC: Audit external function called indirectly via GOT References: <20180317133115.GA4681@gmail.com> <87370txhr1.fsf@mid.deneb.enyo.de> <3a203b82-1247-5538-4848-92c9227cc77e@redhat.com> Date: Mon, 01 Jan 2018 00:00:00 -0000 In-Reply-To: <3a203b82-1247-5538-4848-92c9227cc77e@redhat.com> (Carlos O'Donell's message of "Wed, 21 Mar 2018 15:54:22 -0600") Message-ID: <87po3wo589.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00009.txt.bz2 * Carlos O'Donell: > On 03/21/2018 03:04 PM, Florian Weimer wrote: >> * H. J. Lu: >> >>>> Could we ship a template for the PLT entries in ld.so instead? And if >>>> needed, map it from the file together with an address array, like this? >>> >>> This won't work since linker needs to know exactly PLT layout to generate >>> JUMP_SLOT relocations for LD_AUDIT. >> >> Why would we need JUMP_SLOT relocations? Couldn't we install suitable >> interceptors for GLOB_DAT relocations instead, as long as they resolve >> to external function symbols? > > I think your suggestion might work, but why alter the existing > behaviour which users expect and is documented in countless linker > text books? If you have references, please add them to the glibc implementation or the wiki. It would certainly help those who are trying to work on the code. My understanding is that the whole thing is quite underdocumented. For LD_AUDIT in particular, we only have the Solaris documentation, and that's for an independent implementation. > Existing tooling to process such relocations and entries could > remain unchanged and we would continue to support LD_AUDIT. My understanding is that H.J.'s proposal requires changes when running in non-audit mode. It certainly requires relinking all binaries, perhaps even with special flags. Using ld.so-generated thunks for all GLOB_DAT function symbol relocations would happen in audit mode only and should work with existing binaries which were built with -Wl,-z,now.