From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 53A833950E48 for ; Thu, 13 Jan 2022 13:19:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 53A833950E48 Received: by mail-pl1-x630.google.com with SMTP id i6so9908922pla.0 for ; Thu, 13 Jan 2022 05:19:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M6kMfTDKeqn832w5Vevqjnl97SdBzaSc5D9TG9Un67A=; b=qZrstM0ijhNAq8+VFxE9UdxQ/Pf7xwQ8UPe6vIpAaBDuyMa3I6HShNun+300Qimc13 73df1HvbfYq1sPXzxjtlRGJ0eeLwSdtziLhalgs0O7IowA/TlZlN/6nF97RYITO/j4kb Qm7mw7d18Oh14bu9EPgLFX2Rar426sUFniEZDaznKmdBJJJlHQs19SdQzn86D3WK+zAo urB8f8kLg9XEm1QUlq/sPBNhMvsVLy6GkPcoQrRGZft//PJIyG+DjyzhKf3NaZP2OFkP G17AS4KButwNtVB39hpFB71p7wlNovB5P7BBiIr2/iJKufbzsUAFENpzB+fWzFNuMabJ 7y8A== X-Gm-Message-State: AOAM533FpU3OpW4UUOc2IsZfYhzQji/nFfJ6aD/sZNrwsmJKBYVIEwW4 Laut5TZ5zkg/B9BRpYEX361PgRnkaX4YcZy9k+JSr9/VOzM= X-Google-Smtp-Source: ABdhPJzG0z4MsyIdpqfhKr3oasDTxXnHKqf2IM2NqIcXHjsYHdA+1xTVF6HY7SqekSIkNypNI7GRx5CIhKed7DuneNE= X-Received: by 2002:a63:b24e:: with SMTP id t14mr3876443pgo.381.1642079998325; Thu, 13 Jan 2022 05:19:58 -0800 (PST) MIME-Version: 1.0 References: <20220111021241.1937265-1-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 13 Jan 2022 05:19:22 -0800 Message-ID: Subject: Re: [PATCH] elf: Remove the 1-page gap before the RELRO segment To: Alan Modra Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3022.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 13:20:00 -0000 On Thu, Jan 13, 2022 at 4:52 AM Alan Modra wrote: > > On Mon, Jan 10, 2022 at 06:12:41PM -0800, H.J. Lu via Binutils wrote: > > The existing RELRO scheme may leave a 1-page gap before the RELRO segment > > and align the end of the RELRO segment to the page size: > > > > [18] .eh_frame PROGBITS 408fa0 008fa0 005e80 00 A 0 0 8 > > [19] .init_array INIT_ARRAY 410de0 00fde0 000008 08 WA 0 0 8 > > [20] .fini_array FINI_ARRAY 410de8 00fde8 000008 08 WA 0 0 8 > > [21] .dynamic DYNAMIC 410df0 00fdf0 000200 10 WA 7 0 8 > > [22] .got PROGBITS 410ff0 00fff0 000010 08 WA 0 0 8 > > [23] .got.plt PROGBITS 411000 010000 000048 08 WA 0 0 8 > > Do you know what is going wrong with the relro section layout for this > to occur? > > In this particular case, the end of the read-only segment is at > 0x408fa0 + 0x5e80 = 0x40ee20. My guess is that layout of the > following rw sections starts on the next page plus current offset > within page, the standard choice to minimise disk pages. ie. We start > at 0x40fe20. Then discover that this puts .got.plt at 0x40fe20 + 8 + > 8 + 0x200 + 0x10 = 0x40f040. However, we want this to be on a page > boundary so that the relro segment ends on a page boundary. So we > bump 0x40f040 up to 0x411000 and calculate backwards from there to > arrive at .init_array with a vma of 0x410de0. Resulting in the > 0x40f000 page being unused. > > If instead we start relro layout on the next page, we'd start laying > out at 0x40f000 rather than 0x40fe20. I think that would be the But if the prior ro section size is greater than one page, we want to subtract 1 page: + /* If the preceding section size is greater than the maximum + page size, subtract the maximum page size. Otherwise, + align the RELRO segment to the maximum page size. */ + if (prev_sec->size > seg->maxpagesize) + { + desired_end -= seg->maxpagesize; + relro_end -= seg->maxpagesize; + } + else + { + desired_end &= ~(seg->maxpagesize - 1); + relro_end &= ~(seg->maxpagesize - 1); + } + } > correct thing to do rather than fixing up afterwards as your patch > does. > I am checking in my patch as Nick has approved it. There is a possibility that one 1-page gap may be needed to maintain the section alignment. My patch checks it and includes many testcase adjustments to remove one 1-page gap. Can you update the RELRO segment algorithm to make my fixup unnecessary? Thanks. -- H.J.