From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87209 invoked by alias); 21 Mar 2018 17:16:30 -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 86863 invoked by uid 89); 21 Mar 2018 17:16:30 -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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=lazy, H*r:10.223.150, Auditing, auditing X-Spam-Status: No, score=-1.9 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-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Mar 2018 17:16:28 +0000 Received: by mail-wm0-f44.google.com with SMTP id a20so22897035wmd.1 for ; Wed, 21 Mar 2018 10:16:28 -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=bZOakS8Qxz0RhFk//UXqbRFwzKEmf8lwxBgkg0NqMUE=; b=U1MDKgWGUFWPyN+yMohaZL0ZfUHK0ivhmLdBOazAUySvPLZmZn3XPak+KMnnZe1dwU lmjOAMbt77+02O0GDBWUPdt0VN0C/iYCEXi2I+uRoHT66XlZVJqjuQB0B6tPwfIsegCP 6aLM8bQuqGNAFudj3deL6ijbRzpWyikFkOH66TneY8ka8mkaI7ZRAgL4gzi0Te/36ffp 8GNQn3uBPv/ovEp01kLAReOdfzT1X23jleP+EEedhXhYdwIgTGBMgJhMV946K69OIypa LRMSD4teE1/+7kDMSjgmFXfU+cj8UhqlPzdkaYpq2z8WgS8YA3FS0C5rDmJMu5uqAIHO p4tQ== 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=bZOakS8Qxz0RhFk//UXqbRFwzKEmf8lwxBgkg0NqMUE=; b=EsODDVOWOX4gFzF6LOUgi+3Gl1Vk8Z4fd47U7NiRMBhttQuMBMlNQruqFL7GKWjEst aHeHuCXS5jlG+Ps12wYPG3hiZFIltgaG4dI3bHZaEgZBqyIhUBBeXA4G+N0cRT8YS765 zqNAVxMQCnEltikpjNobrt2J8Yq+wNTcFxwplbcA3o3r3GlPlCdRUwsJGEfFPjYiiNqH 3Q0AIe85OIHybuoF5KEHfPNr6pStFMso5sfPgb3yW5WpyzSMKykNPed7b3uNEPkcIGUt Thu0S9jfZ8hR5273GbJzZMPIWgIJyC2xH6uKyaAEADjBDiyey0pLgnEgx5WiEYEv15o0 fEpQ== X-Gm-Message-State: AElRT7E6p4DALWcnXi1RPNgfXVOm5vMtj/fafrZevP06j1HAiXP09wBk 6lYHqslLC1QaFkXW1VezsYrvNjKYGYMtHR6bFYM9Uw== X-Google-Smtp-Source: AG47ELsY6AcyPHe9fjQOWb+cRofS20Vsk2MaKeEPlRJZr13j2sgPMBAVmuacjd0I2dRLG37yXBVzIU6ZcKS8p43+wmE= X-Received: by 10.28.227.66 with SMTP id a63mr3116110wmh.128.1521652586535; Wed, 21 Mar 2018 10:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.146 with HTTP; Wed, 21 Mar 2018 10:16:25 -0700 (PDT) In-Reply-To: <20180317133115.GA4681@gmail.com> References: <20180317133115.GA4681@gmail.com> From: Cary Coutant Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Audit external function called indirectly via GOT To: generic-abi@googlegroups.com Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00004.txt.bz2 > Auditing of external function calls and their return values relies on > lazy binding with PLT. When external functions are called indirectly > via GOT without using PLT, auditing stops working. Could you give a little background here? Why does it stop working? What does auditing rely on? I didn't find anything about this in the psABI document. > Here is a proposal to support auditing of external function called > indirectly via GOT: > > 1. Add optional dynamic tags: > > #define DT_GNU_PLT 0x6ffffef4 /* Address of PLT section */ > #define DT_GNU_PLTSZ 0x6ffffdf1 /* Size of PLT section */ > #define DT_GNU_PLTENT 0x6ffffdf2 /* Size of one PLT entry */ > #define DT_GNU_PLT0SZ 0x6ffffdf3 /* Size of the first PLT entry */ > #define DT_GNU_PLTGOTSZ 0x6ffffdf4 /* Size of PLTGOT section */ > > and update DT_FLAGS_1 with: > > #define DF_1_JMPRELIGN 0x10000000 /* DT_JMPREL can be ignored */ > 2. Linker creates PLT entries for auditing external function calls via > GOT and sets DT_GNU_PLT, DT_GNU_PLTSZ, DT_GNU_PLTENT, DT_GNU_PLT0SZ and > DT_GNU_PLTGOTSZ. If PLT isn't required for lazy binding, set the > DF_1_JMPRELIGN bit in DT_FLAGS_1. > 3. When auditing is enabled at run-time, dynamic linker resolves GLOB_DAT > relocation to its corresponding PLT entry by finding JUMP_SLOT relocation > against the same function and use its PLT slot as the function address. > On x86, the first PLT entry and the 3 GOT slots are reserved. GOT slot > is (JUMP_SLOT relocation offset - DT_PLTGOT) / size of GOT entry. PLT > offset is (GOT slot - 3) * DT_GNU_PLTENT + DT_GNU_PLT0SZ. PLT address > is DT_GNU_PLT + PLT offset. DT_GNU_PLT, DT_GNU_PLTSZ, DT_PLTGOT and > DT_GNU_PLTGOTSZ can be used to check if GOT and PLT offsets are within > range. > 4. If DF_1_JMPRELIGN is set, dynamic linker can ignore DT_JMPREL when > lazy binding is disabled. > > Any comments? Maybe a little more background would help me understand this better, but I don't see why the GOT slots aren't being (or couldn't be) statically relocated to point to the PLT slots. If the linker does that, all the dynamic loader has to do is ignore the JMPREL relocations at startup, and let lazy binding happen. I don't see why it would need to go through this complicated matching process. (One trivial comment on your choice of naming: I can't see "JMPRELIGN" without reading it as a misspelled "jump re-align"! Maybe "IGN_JMPREL" would be better for human readers.) -cary