From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24261 invoked by alias); 28 Mar 2018 02:59:22 -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 24249 invoked by uid 89); 28 Mar 2018 02:59:21 -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.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=ccoutant@gmail.com, ccoutantgmailcom X-Spam-Status: No, score=-2.6 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-ot0-f171.google.com Received: from mail-ot0-f171.google.com (HELO mail-ot0-f171.google.com) (74.125.82.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Mar 2018 02:59:20 +0000 Received: by mail-ot0-f171.google.com with SMTP id w12-v6so1086766otj.7 for ; Tue, 27 Mar 2018 19:59:19 -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=SeOuH/3zfg3pVjWaQlYQoQXTqRS3r3uIPyqlYjtFhlw=; b=PyEKQYXHQeNt+EmsjQs93A9skx1dcRAv1yj+HWgBO2VC506m5kVs8CmYwF3qreUX7D nxIHV+NLkwr1AB/n/2tuMI4MMCDywBpr4yDl9EMOOs6q+h4yDZcjYwfYDwtrJd/iiVRV cj6QcT0iwsafWppk84ThJHk8XiLdL6Mobx0XkYRS1ybUn7Ry2i+q565fFSbgGiXNTF4N I1v3PNJwbnzsC1fJGq0rhlkFd/igWNv/ADI2E7Cn6zOIjYqn3kOoNA48a5LMvEkdcKjK LeVO8w5usjotma+i2ocS+/6gxjwFPKb4dFsugWxyvkCUsOJhyrpMuCoyObP+OwdzHSiu x+cw== 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=SeOuH/3zfg3pVjWaQlYQoQXTqRS3r3uIPyqlYjtFhlw=; b=LqyNVwhEvxmW5nTgu+EeMaay36TZBF5LG6LjNAnnrmK7scjMNilHtrKQjq6j/uaHKH bay/dl1RaJO78Sw8dDDu6c+mmYrrtPOQ2ZmBGNxT0LhL/TzNJSPkR4RVdL0YfCv3tT8G e7bIYeY1pMC5d+fIVfb0toooMAWkcA2NC2DZMe//Pmwgch9SZgKl7pnJ+FtnhhKiGh3F cuynlxnJO6nLCmsPN9aPOs+8jgDHNLNyFpQNpnUEtQnb3f9GLnQZXiOfT5hvSEiMQ6lp bD24H0hOv8mBAu2LOFGmJ2xsTBrqD7I5TY2reK4sRMjhMiujQf7R26Ht4+kNW2tETIiZ JUIw== X-Gm-Message-State: ALQs6tCm4R0INzLYD7uu+0QpIE17UbMG38mjav77M8fmYp5/AJ9LnD8G mtRBDIMPe3enyKhvw4Bux5ePrQDtuVN+uFZHy68= X-Google-Smtp-Source: AIpwx4/Oj+GAwiP8KXynKbIbdNWW8FqV6/kQwXNjtmXIYzo0TEMrGZkXEy9RRbIjVhJZJVgEDTj9BnepOct4u5qSvG8= X-Received: by 2002:a9d:3464:: with SMTP id v91-v6mr1059226otb.159.1522205958214; Tue, 27 Mar 2018 19:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.190.152 with HTTP; Tue, 27 Mar 2018 19:59:17 -0700 (PDT) In-Reply-To: References: <20180317133115.GA4681@gmail.com> <87370txhr1.fsf@mid.deneb.enyo.de> <3a203b82-1247-5538-4848-92c9227cc77e@redhat.com> <87po3wo589.fsf@mid.deneb.enyo.de> <76f5551d-e8dc-4915-e3d8-54a2305a5718@redhat.com> 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: Cary Coutant Cc: Generic System V Application Binary Interface , Florian Weimer , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00029.txt.bz2 On Tue, Mar 27, 2018 at 6:39 PM, Cary Coutant wrote: > I haven't seen a response yet to the primary point I was trying to make: > >> My suggestion was that the GOT entry could be statically initialized >> by the linker to point to the provisional PLT entry, rather than >> forcing the dynamic loader to go through all this messy computation. >> If auditing is not enabled, it would process the GLOB_DAT relocation >> normally, and set the GOT entry to point to the actual function, >> bypassing the provisional PLT and PLTGOT entries completely. If >> auditing is enabled, it could simply ignore the GLOB_DAT relocation >> (or, if the binary is PIE, it could process it as a RELATIVE >> relocation), and the -fno-plt calls will end up jumping to the >> provisional PLT entry. >> >> (This is already how we handle the PLTGOT entries: the linker >> statically initializes the entries to point to part (b)* of the PLT >> entry, while putting JUMP_SLOT relocations for those entries into the >> JMPREL table.) >> >> I think if you do that, none of these extra dynamic table entries will >> be needed, ... Your scheme is very similar to mine. Both generate one GLOB_DAT and one JUMP_SLOT relocation for the same function symbol. But only one of them should be used at run-time. Your scheme may be simpler when LD_AUDIT is used since you don't need to update GOT slot. But you still need to decide if a GLOB_DAT relocation should be skipped for LD_AUDIT. > ... or this secondary point: > >> ... except for the IGNORE_JMPREL flag that indicates there are >> no JMPREL slots other than those for the provisional PLT entries. How >> useful is that flag? If the final program has even one external call >> that was *not* compiled with -fno-plt, you won't be able to set it. >> Would it be better to partition the JMPREL and PLT tables into >> "regular" and "provisional" entries? That would take just a single new >> DT_PROVISIONAL_JMPREL entry to tell the dynamic loader where the >> JMPREL entries for the provisional PLT entries begin; it can ignore >> everything past that point when auditing is turned off. > This sounds a good idea.. I will take a look. -- H.J.