From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85418 invoked by alias); 22 Mar 2018 13:31:03 -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 85371 invoked by uid 89); 22 Mar 2018 13:30:59 -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=-3.3 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, HX-Received:6589, HX-Received:sk:c9-v6mr X-Spam-Status: No, score=-3.3 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-pl0-f43.google.com Received: from mail-pl0-f43.google.com (HELO mail-pl0-f43.google.com) (209.85.160.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 13:30:54 +0000 Received: by mail-pl0-f43.google.com with SMTP id k22-v6so5269362pls.6 for ; Thu, 22 Mar 2018 06:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=czKlLJn5gkWh2ahtisrYTaiwqlk1KkD1TgJhBDGKG8A=; b=kIQhTVkNlY2ZacBKGNpeEZCdkCvQVxPiFEtHKOvEaGfVBVzxC7aHnPoEgekb8lB1Tz n497SBrFCtD9NHFQNHWMJEVzde6CckwtInx0z+rE6eCsuLu968+BLisSReIJRP5xvAcv jgyuq87yRWSPcmSpd1BKVZvAqffjtE0Fvy3b4OvW7sHB2Y2k5SDOqs4UaM+a0W3uEehC b1nBnxFdvLEKRtmc86U4+mYd7FVchrfcmW02CFLiBCXkdqF6ovV16jWlY2nQbybnHOzJ R22lr96mRS2mPkRzc4L7UaNbH4EF2/N+TL9Kq41YwMUmbqpoGviOEyo/k1fJfvPArz4R dg6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=czKlLJn5gkWh2ahtisrYTaiwqlk1KkD1TgJhBDGKG8A=; b=loKXgosXiFaOhStx5RacXydXiMTYzlDYJjTvDZXpC24eaqz+WVyNdcDLEziWKHSehz vSq63Qy/L9AMEeO3gjFkW7xMDqxAoapTdsL+h+4CnqSb3jzLb8FCmKaGdBLDwdToh9Jw SzDmvzO851VhLro+28oJ0EJm/4SlbFl6CzFzfbvpBi5UQXaeTm9Wge/ccgXutQH3ohFs lcZ9ZiEXsk6vUcyWu+9g48NyFTUgTEpNdUgNfIAdOwqrjZLoP1BKNbkv+6E7d27RmFWX HRMXFfGC1Ig6VTgPK27hmhtRn6fK+CsftDIR7Dp2cg88LH72ZmRgPWs50a9y7xe43dlc /LrQ== X-Gm-Message-State: AElRT7EQGtGSjWfo9hOBKs6/xbbWQEAIk3+WMrJ2hxye+5Xw/z16L36C wW5lfcjKmMtDTkfCM+Do0iM= X-Google-Smtp-Source: AG47ELvKKqAZ027/sPZo8gjIseNxkMqdWj23L32qV6Mty0xHiX2PG3QY9iEr4K5z7cXynKR6a0WXig== X-Received: by 2002:a17:902:6589:: with SMTP id c9-v6mr20534481plk.215.1521725440427; Thu, 22 Mar 2018 06:30:40 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-175-241-133.hdcz1.win.bigpond.net.au. [58.175.241.133]) by smtp.gmail.com with ESMTPSA id d75sm12215422pga.38.2018.03.22.06.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Mar 2018 06:30:39 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 5A32DC04D1; Fri, 23 Mar 2018 00:00:34 +1030 (ACDT) Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Alan Modra To: generic-abi@googlegroups.com Cc: Carlos O'Donell , gnu-gabi@sourceware.org Subject: Re: RFC: Audit external function called indirectly via GOT Message-ID: <20180322133034.GR3812@bubble.grove.modra.org> References: <20180317133115.GA4681@gmail.com> <20180322122957.GQ3812@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00014.txt.bz2 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. -- Alan Modra Australia Development Lab, IBM