From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34489 invoked by alias); 8 May 2017 04:35:19 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 34468 invoked by uid 89); 8 May 2017 04:35:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=road, act, Full X-HELO: mail-qk0-f178.google.com Received: from mail-qk0-f178.google.com (HELO mail-qk0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 May 2017 04:35:15 +0000 Received: by mail-qk0-f178.google.com with SMTP id y201so10441970qka.0 for ; Sun, 07 May 2017 21:35:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=R1/ClmNJB0RZYfHh4g7ZcvB5zWIGrZ7UQKaB1Aj27Vs=; b=UZx8sS31Yv4zPdDwnsCKSS9+UbeoCGC5U/sqzks0C+34UnEIBuB61T0/wsKPvpZ+Jh w2RRRtHonJie1VjlGTUMSRxc7vBLrLIOAZc8ks5y6GdEGMwqmyAFHHymO921ZtMjwwxI sondpxhnAsflzgS9UOXMdyhepQU5CnTZdis0sEUbW2xbgWmW7HFbCiWZbkMjsrB5oiCV J77hI0brsQTxRf4/eAbvRmmFOAxZOA0xlD8tBInShe0GV50I9nxE4rMy7jo0Av4X4++8 ALrAaPqwdjnm5BLc1Uo9SFvxG1nstSxfW9prAYOcvf1LXOyFVVfL7ZFJGBcOke7j79E7 TaEA== X-Gm-Message-State: AODbwcBj5EVF8QQp81Y09XYLsqLMAtXx2NFPUJrgOfcsVvFOloxLDV0w Vv28TsLWMOaFwVU1 X-Received: by 10.55.8.2 with SMTP id 2mr22297387qki.269.1494218116273; Sun, 07 May 2017 21:35:16 -0700 (PDT) Received: from [192.168.1.200] (otwaon234vw-lp130-01-184-145-137-27.dsl.bell.ca. [184.145.137.27]) by smtp.gmail.com with ESMTPSA id z33sm9518966qta.48.2017.05.07.21.35.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 May 2017 21:35:15 -0700 (PDT) Subject: Re: [PATCH] i386: Remove PLT0 and use non-lazy PLT if PLT0 is unused To: Florian Weimer , "H.J. Lu" Cc: binutils@sourceware.org References: <20170502203156.GA11102@intel.com> <20170504163120.GA19140@intel.com> <20170506151138.GA4151@intel.com> From: Carlos O'Donell Message-ID: <86cfe42e-95df-4e84-30ff-c4ec8177cf19@redhat.com> Date: Mon, 08 May 2017 04:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00079.txt.bz2 On 05/06/2017 02:55 PM, Florian Weimer wrote: > On 05/06/2017 05:11 PM, H.J. Lu wrote: >> 1. Call external function. >> 2. Call internal IFUNC function. The best implementation is selected >> for the target processor at run-time. >> 3. Act as the canonical function address. > Audit support is missing from this list. Audit support needs a PLT > stub which calls the audit trampoline with some sort of function > index or address. Correct. > I'm concerned that -z now in recent binutils (even without this > patch) removes audit support, when before, audit support was not > impacted by -z now (I think, I'm not sure on this point). Audit support is currently disabled by `-z now`, since the early relocation processing means there is no chance to audit through the _dl_runtime_profile hook. However, it should IMO not have to be this way. LD_AUDIT could cause RELRO to lock down the GOT entries and have them _always_ go to _dl_runtime_profile, but you still need unique PLT entries for this. Ignoring this missing feature the problem I have is explained below. > We really must avoid hardening flags which have profound semantic > implications on generated binaries because it discourages people from > enabling them. I agree completely. I think the problem that I see is that binutils changes like PLT elision cause PLTREL to be removed which requires glibc changes before any tooling using LD_AUDIT can work properly, and that's a bad sequence of effects. Worse without a PLT you can't even fix these binaries down the road if we enable a Full RELRO LD_AUDIT because you'd need to recompile everything. Optimizations like removing PLT entries should be just that, optimizations that aren't turned on by `-z now`. Though how much is really a question of what we call ABI? Are PLT entries ABI? I would argue they are for developer tooling and LD_AUDIT purposes. -- Cheers, Carlos.