From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126480 invoked by alias); 22 Mar 2018 13:49:10 -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 126467 invoked by uid 89); 22 Mar 2018 13:49:09 -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=amodra@gmail.com, amodragmailcom, Alternate, honest 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-f174.google.com Received: from mail-ot0-f174.google.com (HELO mail-ot0-f174.google.com) (74.125.82.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 13:49:03 +0000 Received: by mail-ot0-f174.google.com with SMTP id 108-v6so9488139otv.3 for ; Thu, 22 Mar 2018 06:49:03 -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=YAUPLxNJSx+VVTLylrb6V5FkJzwUTJwOc2jrWaT/aqU=; b=f+1XkZxFEMWSUryklzf0iiquhb/T9efyR9oZuOopBh41wHETg6mtv9JgMSt42yYIKK FyiHT4kISu1HF8DGiEQ7RkkqLIcxYs5GtjGmUFjiT1L79J4zusLsuodbgx7MwO9HdP2u IGZVWvlPIyVw9NLmjykODlHWS/uVDEtwLTYkSF1vuHHC3aD1NDHLKV1+EaQJMxL0H38X sBMQClL7l0A+mos2pAb7dh60RSM7Qw0wUCdv6r1wm0wVYG3hrAcn2nKf8gZ8QB0vYA5T 8TXw7zI8FOD+PdC2t8MDHscKfefoVLIgo0kdpo1o9pAr9sY2GVa7fOnyZ384V1ErDekv QDtQ== 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=YAUPLxNJSx+VVTLylrb6V5FkJzwUTJwOc2jrWaT/aqU=; b=W4KtvxRhA9VlfN8FO5VO6PD8/uvyFi7utcYZZQxMPiLvnYgvsTae/wmwTVvjjAwsSt KjpB499b4k3YSvVPaims8+ncEUzJhjy0Imwxq0rGHvMnFXGD4X80i+r8aKvP0dW8o0nV 4lRMgO8wkcr3zoOqUyEI/dabDAuz+vFmlYJOWTxz+0qlojmK7q6EWSe2HUxGoDicF/Mv 0F3DgVhHbIy43j7mPqSVclqC0miLdWIhWH3Do78UkyEavECdbd6LYHfqb1RAibM1VtX5 gg/1OFR3UQYPqvxD3J02jYyjnrOVCJK+M4ODr6KiQI7ogwim47cAQfRwzRvCNU9gA31x knSg== X-Gm-Message-State: AElRT7FqJpp7tgdWaxlZZsLDiXG+72PuDRYKYU6YobeEaEWThdqZp/CI g03E36fj0NLfGopP22aevZwOO04x7pwlKFRVzmE= X-Google-Smtp-Source: AIpwx49i25haUnkIFayecoEuCbVAmwToaUxg5+FLZos6oggaSK+R49tTJfT/MOkLh66zdY8xF2NF83GokgOVkJ8InJ8= X-Received: by 2002:a9d:171e:: with SMTP id i30-v6mr277218ota.204.1521726541480; Thu, 22 Mar 2018 06:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.10.20 with HTTP; Thu, 22 Mar 2018 06:49:00 -0700 (PDT) In-Reply-To: <20180322133034.GR3812@bubble.grove.modra.org> References: <20180317133115.GA4681@gmail.com> <20180322122957.GQ3812@bubble.grove.modra.org> <20180322133034.GR3812@bubble.grove.modra.org> 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: Generic System V Application Binary Interface Cc: "Carlos O'Donell" , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00015.txt.bz2 On Thu, Mar 22, 2018 at 6:30 AM, Alan Modra wrote: > On Thu, Mar 22, 2018 at 05:39:18AM -0700, H.J. Lu wrote: >> On Thu, Mar 22, 2018 at 5:29 AM, Alan Modra wrote: >> > On Wed, Mar 21, 2018 at 10:15:26PM -0700, Cary Coutant wrote: >> >> 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. >> >> >> >> -cary >> >> >> >> * I'm using parts (a) and (b) to refer to the two parts of a PLT >> >> entry: (a) an indirect jump via the PLTGOT entry, and (b) code that >> >> jumps to the lazy binding routine, passing the JUMP_SLOT index. >> > >> > Yes, that essentially is what I've done for -fno-plt on powerpc. >> > The call stub code is inlined while the rest of the PLT is more or >> > less unchanged. So you get all of the usual lazy-binding features >> > by default, and can use "-z now -z relro" if you want a read-only >> > PLT. >> > >> >> On x86, PLT is always read-only. The issue is the writable PLTGOT. > > Yes, I do know how the x86 PLT works. (Or to be more honest, how it > used to work..) To be clear, I was using PLT to refer to the whole > scheme, ie. the code to do an indirect jump (x86 .plt), plus a table > of addresses (x86 .plt.got), plus code for lazy binding (x86 .plt > again). Like x86 the powerpc PLT code to do indirect jumps and lazy > binding is read-only nowadays. -fno-plt on powerpc inlines the code > to do the indirect jump, but leaves the table of addresses and the > lazy binding code functionally unchanged. > >> On x86, -fno-plt removes the writable PLTGOT. > > I think that may have been a mistake. You could have kept .plt.got > functionally unchanged, giving you a writable .plt.got by default with > -fno-plt, and read-only when "-z now -z relro". Just like the usual > -fplt case. > This is done on purpose. See "Alternate Code Sequences For Security" chapter on x86-64 psABI version 1.0. -- H.J.