From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50348 invoked by alias); 22 Mar 2018 15:36:59 -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 49922 invoked by uid 89); 22 Mar 2018 15:36:58 -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=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=HX-HELO:sk:mail-qt X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qt0-f181.google.com Received: from mail-qt0-f181.google.com (HELO mail-qt0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 15:36:57 +0000 Received: by mail-qt0-f181.google.com with SMTP id y6so9364916qtm.7 for ; Thu, 22 Mar 2018 08:36:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tAZA+EmbWbz7uI/YG0nlakaDD/D+jlyjvJER5+EpUwc=; b=Lh3x2ol5uwoKq4VlHitlKv8l+Di9Xnu0mSMYuk/lPJk6YCnC5BJYnFTwC651oTegMc 3bj1ssJY1cdxbVknpnLNmQ5j/X0Ieu+TTRgLv8j0e3EpmDelSdgX0p1rIswNyq5wD7A7 ty8FTHtHSy4mgMxjw0FSma52vEr6jGHflrd8KQGAeUVQMJ9L/6AYjBIgCoyK6xb7Tu8x QgyNbIh3W4A4U2SypEwSLU8tpzCyGUprHvNCgZK1QdZ4XW1q2bNVahrgL5K10gWK4bY3 oVoFQt7a6Bopu30zZzOx+1SYPxjnLjTG9/gkoqrYKQyZRWFA2gg/oF7QYVMGpHhE3AoP 4vZQ== X-Gm-Message-State: AElRT7HsWn9nsuY95t4u8Yh2pWCxKbyGzSNQ9p/USaTglCfTJEUc5Omg /lRpw6pKGeUbR48YwsyyJlYgnqKPOvc= X-Google-Smtp-Source: AG47ELsuExLoiG0cAzFCkRk//dB8I8QwhRMHCyrcuLCxbr4rH6qtmE+27njzWN9RtWELCXZMSm0Yww== X-Received: by 10.200.6.205 with SMTP id j13mr35405557qth.102.1521733015028; Thu, 22 Mar 2018 08:36:55 -0700 (PDT) Received: from [10.150.73.95] (198.sub-174-207-13.myvzw.com. [174.207.13.198]) by smtp.gmail.com with ESMTPSA id q184sm5189134qkf.79.2018.03.22.08.36.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Mar 2018 08:36:54 -0700 (PDT) Subject: Re: RFC: Audit external function called indirectly via GOT To: Florian Weimer Cc: "H.J. Lu" , Generic System V Application Binary Interface , gnu-gabi@sourceware.org References: <20180317133115.GA4681@gmail.com> <87370txhr1.fsf@mid.deneb.enyo.de> <3a203b82-1247-5538-4848-92c9227cc77e@redhat.com> <87po3wo589.fsf@mid.deneb.enyo.de> From: Carlos O'Donell Message-ID: <76f5551d-e8dc-4915-e3d8-54a2305a5718@redhat.com> Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87po3wo589.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00016.txt.bz2 On 03/22/2018 03:59 AM, Florian Weimer wrote: > * 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. Well, Levin's "Linker's and Loaders" https://www.iecc.com/linker/linker10.html, is the immediate reference that I have on my shelf, and that developers working on glibc/binutils should read. Likewise "Computer Systems: A Programmer's Perspective" by Bryant and O'Halloran. Chapter 7 "Linking." which covers explicitly how the present GOT and PLT work. I have added these under developer resources on the wiki front page. > 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. Yes, for LD_AUDIT it is underdocumented, here we have only the linux man pages project pages. >> 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. It would require a relink only to fix existing binaries which are broken by the use of -fno-plt, which is not an option that has seen general use anywhere that I am aware of. > 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. This is a very good reason to prefer one method over another, that we could fix existing binaries. However, I still think the complexity of such a fix outweighs what we are trying to fix. Do we have another use for such stubs? Today we have to admit that -fno-plt is not compatible with auditing. I would like to change that to ensure that in future releases we are able to let users use -fno-plt *and* auditing. Cheers, Carlos.