From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31864 invoked by alias); 24 Jun 2018 18:04:35 -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 31852 invoked by uid 89); 24 Jun 2018 18:04:35 -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=fourth, H*Ad:U*nickc, presence, relocation 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-ua0-f175.google.com Received: from mail-ua0-f175.google.com (HELO mail-ua0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Jun 2018 18:04:33 +0000 Received: by mail-ua0-f175.google.com with SMTP id s13-v6so7243014uad.2 for ; Sun, 24 Jun 2018 11:04:32 -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=KtfGASMJZqbo+vVS3HjlBwhDeaFeFxivyRGcq1qHERs=; b=ApnB2iXKAP+Mb3yqMz9YZEbdWzfeM8Nh3uLSRWGu1TW5n4sCSByqouyGZdTN4FUPNb Erl/eGWbPZUVWsjeeE40XLAOekHnaAcetuYIDqCEvsFVnaICEBzCq5WHV0494BFxTr7U 63rXzJkerpkPI1rSTtkRgq5n9DBxmo1TBqbM/WdtHesW4qFf9BnQoz2IGHlKEsc/95Hv QtiEmywa5LTc0vvVXc0tdhHp4LOZK/zfFHClbgHsbYyQHAkOayJcqvnS/ibCQTzcMcYR 2zKpisdYcpXZF/4u8sI88yIfW9XwDe+shFb5oBYj5S5zQ8Zbjdy9LVXSUyS89hTrhxv0 1wOw== 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=KtfGASMJZqbo+vVS3HjlBwhDeaFeFxivyRGcq1qHERs=; b=eNPPxqoV8luYLKIUSSddhHz7jB2khMeybpJx+bAE5D/eu10+eQ75Hf9NSZfWowIHkn vfFlKGeWPtE2ltEeDcIrAJEE0X+9K0Rv//BZikDuW9lPmjTOMBRhMYojt9MFNFXqVoNj Vg9APceBJV9Xbt2ZxO+3AcqprJUywZDVTO5ZM9C9+kg7j0ArCBf63hA9X0BxaThYP1VD PbWtC9BfN9vVwaaFr1iywgqdUU7x3B3/XY1V4olhmN4Rhle9waT2NtOHL7SH6ptPZsXt Gk7hxFSXnp52cagQpkzIXngOGXOe9kABSw3kk4HG4jfKD3UwhtmU0/H6IV0dwVATZ188 4RvQ== X-Gm-Message-State: APt69E2gei05JdpgYX8tZBOyjwlLZC7aRpacJlcNGyztwZ8b8WJ1xdUU SgE9ixemILicXZMwUSuTp0twOdWICfit3bbL+7I= X-Google-Smtp-Source: ADUXVKJ6msEaWsoyFqlfVjppTbRnXYNoHX4UOhqVv7I4H1Ob/wqfTpWg5q8xpuZZnVqJpdzXqCTxfNfkgG36gJApsGY= X-Received: by 2002:ab0:136c:: with SMTP id h41-v6mr6565841uae.193.1529863470862; Sun, 24 Jun 2018 11:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:d90a:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 11:04:29 -0700 (PDT) In-Reply-To: References: <87sh5hadd6.fsf@redhat.com> <83d583d0-884e-4208-436e-5b25cbb6ce5a@redhat.com> From: Cary Coutant Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END To: Florian Weimer Cc: Nick Clifton , gnu-gabi@sourceware.org, "H.J. Lu" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00009.txt.bz2 >> Fourth: Isn't the size of .got.plt inferrable from DT_PLTRELSZ? Divide >> that by the size of each relocation (DT_PLTREL == DT_REL ? DT_RELENT : >> DT_RELAENT), then multiply by the size of the PLTGOT entry (4 or 8), >> then add the three reserved entries. There's a one-to-one relationship >> between the PLT and the PLTGOT, and every PLTGOT entry must have a >> relocation. > > The PLT count wouldn't include the padding at the end of the section, so it > doesn't confer the required information. That plus a simple flag does, though. >> Fifth: If all you're trying to say is "the .got.plt section is >> isolated on its own pages", couldn't you just use one of the DT_FLAGS >> or DT_FLAGS_1? Letting the presence of an END or SZ entry signal this >> condition is a bit risky -- what if someone decides they'd like to >> record the size of .got.plt even when it's not isolated on its own >> pages? > > Well, isn't this a problem no matter what we specify? That someone might > provide incorrect information? If we use a number, at least disagreement > about the run-time page size isn't a source of potential issues. My point is that a DT_PLTGOTSZ entry could be useful on its own to indicate the size of the PLT GOT. If you make it *also* imply that the PLT GOT is isolated on its own pages, you're pre-empting that meaning of the tag (which, given the name, would be the most obvious meaning). Although I guess DT_PLTGOTSZ could be taken to mean: "Here's the size of the PLT GOT, possibly including any trailing padding intended to pad it out to a page boundary. If it works out that the beginning and end of the segment are both at page boundaries, then it's possible to make it relro." In other words, the tag's presence doesn't -- on its own -- imply that the PLT GOT has been placed on separate pages, but provides the information to determine whether it has. That leads me to another question: How would this be different from -z relro -z now? It looks to me like a binary with such a PLT GOT would be nothing more than a -z relro -z now binary where nothing but the .got.plt section ends up as RELRO. So why not just use the PT_GNU_RELRO program header for this? -cary