From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119622 invoked by alias); 22 Mar 2018 11:14:24 -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 119223 invoked by uid 89); 22 Mar 2018 11:14:24 -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.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS 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-oi0-f44.google.com Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com) (209.85.218.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 11:14:22 +0000 Received: by mail-oi0-f44.google.com with SMTP id 1-v6so1246596oix.7 for ; Thu, 22 Mar 2018 04:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oRXx+wXzAreAzOjql0iWhCbVc5HBPc1iJBvK5P+qong=; b=bQR9mRI9NSGa83JaJglAR31HfnItdpmRmDFiMCK7Vp/L1I0na8EdDKiFIRZMQU4kTd JIldp5NWdRzj+cdFOU/t3QafcdxyRDRGSPLlLK2ZoQM9GdC9ugLGzpyxyEne7Hvd9YfG V18dQfIhvxu0Y9pLxz7B3dAt4qZS/3DsVBFH0t5d8JCSj3s91nbzmRAjpwiWumf+w0RY EVCVicrfFZ/AWLLoMgWCPgkfASSnTt6x12VWpAe6g/GE05gIpR4tXZW49Nzfr1b+lRUS 6h+qMdA3i7qD30E8FgDn7Wt3imaTZ7tf2E7FsTLQezDFNOpI0lOaLzIxywQCHVTTyo7F yRTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oRXx+wXzAreAzOjql0iWhCbVc5HBPc1iJBvK5P+qong=; b=bNCPctpRfVJsr8ISLg8RInT/MM97OEC7rEBe7+SxBtkeQHHUmdzS5xCTFVKVIcJiVB upGj2+lzF5Erxjx6p6Glm5mOdqJV6GJj3d99wExIItmHFiE+cnbFfFGsSLyWDLDOvWVx 7kg+ZDYliipbcRQY6dxyp+d/sHZzgv7uTUnaXrw1imJDoQoR4YqXfkVK9NGnySaZNC7n yKJD4Ui7qITlKdJ6yZqngpJJENJX22b3QLkfg0HMX1RUtp4aL0Z8mUeOaU37/e7CeXTy jhon7ojBW3FvJ7pC34EXTbthf+zmKKkycyZ1llmucfEFoMFb1sZzJ7i65ApltdqZSX2Q GJ8w== X-Gm-Message-State: AElRT7HrACdkVbj/iaJE2V2JRonWLu+L5Nm6ISPnYR2p0tUtfHy9GJ94 WACItPvK5x7Gn1wqdbrbDx05o4sylXqgYru+wEs= X-Google-Smtp-Source: AG47ELt/ctYRch0e4jusw3MLMtbOjMo/A3ZVhglx/KgTUz+pPwnQbFAqMuVZqCYwfNQU0zCcXE1WRrAvycsAuKkkRVw= X-Received: by 10.202.199.67 with SMTP id x64mr6311675oif.100.1521717260635; Thu, 22 Mar 2018 04:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.10.20 with HTTP; Thu, 22 Mar 2018 04:14:19 -0700 (PDT) In-Reply-To: <87po3wo589.fsf@mid.deneb.enyo.de> 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: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Audit external function called indirectly via GOT To: Florian Weimer Cc: "Carlos O'Donell" , Generic System V Application Binary Interface , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00011.txt.bz2 On Thu, Mar 22, 2018 at 1: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. > > 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. Please see https://github.com/hjl-tools/glibc/tree/hjl/plt/audit and https://github.com/hjl-tools/binutils-gdb/tree/users/hjl/plt/audit for my glibc and binutils implementations. My changes are relatively small and have minimum overhead when LD_AUDIT isn't used. > 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. It means to put parts of ld into ld.so. This is a much bigger change. -- H.J.