From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51959 invoked by alias); 22 Mar 2018 16:02:52 -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 51941 invoked by uid 89); 22 Mar 2018 16:02:51 -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.0 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.0 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-wr0-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 16:02:45 +0000 Received: by mail-wr0-f180.google.com with SMTP id h2so9245197wre.12 for ; Thu, 22 Mar 2018 09:02:44 -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=MmsiLK8/RRdG/SQT2qXf1aA9WN9VgY9gv9TXsCy1pt8=; b=DIlD1CqqqIvOc9ccIfjvhuoaQNFQPrsjoCKNwIUwe0LdffmkDMzv3JBh4J9Rqzq844 yuWRqHwwlJCD0z2sdz+Nv0C3Swxfty4nGRPtyuKGEKFQWCOUjQJCmj8ZMWsXkTYnkqVD oRVfYxvGSU4+7gh8TgqXZfzefCFiihYJYsY+13Cccf9bz4jdINQqZFhyoZ5wmyBqRrwR EZKy7YLLC7TKRKrinOWQLUP1IkamlYJGZlTDXLTIUCcgXuuMsUDhWynEQ0dbaz5LEVDp 3E444rR+BjdQS9hsfOIxZWCM5JEf+NNn2yChClTV+L9XBXzuvLuU1AF5zGEAWEBz3ayk Ujmw== 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=MmsiLK8/RRdG/SQT2qXf1aA9WN9VgY9gv9TXsCy1pt8=; b=IL9SDmYcH/pt4D/UhwGwDN1JlYmHtDKSXt8VOnnB9urDYT4pXAMKZHY6aj60ttm1+M 27QudiPgzGYjQuBkgTWlHzOBIEyRdKFMNpok8vMjVQQWV29jZMJ1gYnDiqY78O8qJhr6 Xal1BBgNnSahAFJmKbf9+uO+Gfv//Yie09Xt3dQcjmiYTu3QcCwh3hkY15K8rkM0nicQ X1eVfU5RFkl/oAG+lpU729+yy8CknD2W7EyyfOyE25rNegSDoveMrYDyV8CXQa4cOOx5 n3s4a7Yy7jYQDZm4CPbpw/u6FXOp3BEfF5M4sTrO0+1qhhBwHNRLn/AzXUpwTEbO2VAR t78Q== X-Gm-Message-State: AElRT7Gj3+vJ0fHscBD0tdds6j6xb98toVG5MLc+maJH00k0grYWggNz fe9Eq6kmRD+Z1borOS5N434oSsK0zos7vjBR8gs= X-Google-Smtp-Source: AG47ELta5RTqmQ2nePoaxJMqrvLgrTpAh+MI4k63Cnxhqoft5UZCbMKhjX5iywa7ssZE7PuBdnAE97xW05OgYt6ty8k= X-Received: by 10.223.138.214 with SMTP id z22mr19702340wrz.39.1521734563125; Thu, 22 Mar 2018 09:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.146 with HTTP; Thu, 22 Mar 2018 09:02:42 -0700 (PDT) In-Reply-To: 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: "Carlos O'Donell" , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00018.txt.bz2 >> 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, > > elf_machine_plt_address in my glibc patch: > > https://github.com/hjl-tools/glibc/commit/aa8f2f5b9f395769f30d776649a11c2a045dd9e2 > > has > > if (__glibc_unlikely (GLRO(dl_naudit) > 0) > && map->l_info[ADDRIDX (DT_GNU_PLT)] > && map->l_info[DT_JMPREL] > && ELFW(ST_TYPE) (refsym->st_info) == STT_FUNC) > { > Find the matching JUMP_SLOT relocation. > } > else > Use the original resolution. > > If LD_AUDIT is unused, the whole thing is skipped. > >> 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, 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. > > These new dynamic tags are used to compute PLT offset from GOT offset. > See elf_machine_plt_address in my patch. Kinda reminds me of "These go to 11." What I'm suggesting eliminates the need for the dynamic loader to compute the PLT offset from the GOT offset, and therefore eliminates the need for all these additional DT entries. >> I suppose you may also want to partition the GLOB_DAT relocations, so >> that the dynamic loader can easily figure out which ones to ignore >> when auditing is enabled. That would take another dynamic table entry. >> >> Now, why do we need both the regular GOT entry and the provisional >> PLTGOT entry? If the program is linked with -z relro and lazy binding, >> you can put the GOT entries in the RELRO segment, and the PLTGOT >> entries in writable data. That gives you the security when auditing is >> turned off, and the ability to dynamically patch the PLTGOT when it's >> turned on. In any other case, however, I see no reason to have both. >> If you get rid of the GOT entry, and have the point of call jump >> indirectly through the PLTGOT entry, which is initialized to point to >> part (b) of the PLT entry, everything should work the same as without >> -fno-plt. Essentially, all -fno-plt would do is inline part (a) of the >> PLT entry. > > I want to use both so that GOT is read-only after relocation in > normal case and the writable PLTGOT is only used for LD_AUDIT. But if the program isn't linked with relro, the PLTGOT entries remain writable and you have no need for both. If it's linked with immediate binding and relro, the PLTGOT entries become relro, and again you have no need for both. The only case where you can make an argument for both is when the program is linked with both relro and lazy binding. But I don't see why you need the additional security if you're not bothering to link with immediate binding. -cary