[Bug binutils/28734] error with build-many-glibcs.py

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28734

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Alan Modra <amodra@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9833b7757d246f22db4eb24b8e5db7eb5e05b6d9

commit 9833b7757d246f22db4eb24b8e5db7eb5e05b6d9
Author: Alan Modra <amodra@gmail.com>
Date:   Thu Jan 27 15:17:16 2022 +1030

    PR28824, relro security issues

    Background
    ==========
    There are constraints on layout of binaries to meet demand paging and
    memory protection requirements.  Demand paged binaries must have file
    offset mod pagesize equal to vma mod pagesize.  Memory protection
    (executable, read, write status) can only change at page boundaries.
    The linker's MAXPAGESIZE variable gives the page size for these layout
    constraints.

    In a typical basic executable with two memory segments, text (RE) and
    data (RW), the data segment must start on a different page to the
    last text segment page.  For example, with 64k pages and a small
    executable of 48k text and 1k data, the text segment might start at
    address 0x10000 and data at 0x20000 for a total of two 64k memory
    pages.  Demand paging would require the image on disk to be 64k+1k
    in size.  We can do better than that.  If the data segment instead
    starts at 0x2c000 (the end of the text segment plus one 64k page) then
    there are still only two memory pages, but the disk image is now
    smaller, 48k+1k in size.  This is why the linker normally starts the
    data segment at the end of the text segment plus one page.  That
    simple heuristic isn't ideal in all cases.  Changing our simple
    example to one with 64k-1 text size, following that heuristic would
    result in data starting at 0x2ffff.  Now we have two 64k memory data
    pages for a data segment of 1k!  If the data segment instead started
    at 0x30000 we'd get a single data segment page at the cost of 1 byte
    extra in the disk image, which is likely a good trade-off.  So the
    linker does adjust the simple heuristic.  Just how much disk image
    size increase is allowed is controlled by the linker's COMMONPAGESIZE
    variable.

    A PT_GNU_RELRO segment overlays the initial part of the data segment,
    saying that those pages should be made read-only after relocation by
    the dynamic loader.  Page granularity for memory protection means that
    the end of the relro segment must be at a page boundary.

    The problem
    ===========
    Unfortunately most targets currently only align the end of the relro
    segment to COMMONPAGESIZE.  That results in only partial relro
    protection if an executable is running with MAXPAGESIZE pages, since
    any part of the relro segment past the last MAXPAGESIZE boundary can't
    be made read-only without also affecting sections past the end of the
    relro segment.  I believe this problem arose because x86 always runs
    with 4k (COMMPAGESIZE) memory pages, and therefore using a larger
    MAXPAGESIZE on x86 is for reasons other than the demand paging and
    memory page protection boundary requirements.

    The solution
    ============
    Always end the relro segment on a MAXPAGESIZE boundary, except for
    x86.  Note that the relro segment, comprising of sections at the start
    of the data segment, is sized according to how those sections are laid
    out.  That means the start of the relro segment is fixed relative to
    its end.  Which also means the start of the data segment must be at a
    fixed address mod MAXPAGESIZE.  So for relro the linker can't play
    games with the start of the data segment to save disk space.  At
    least, not without introducing gaps between the relro sections.  In
    fact, because the linker was starting layout using its simple
    heuristic of starting the data segment at the end of the text segment
    plus one page, it was sometimes introducing page gaps for no reason.
    See pr28743.

            PR 28824
            PR 28734
            * ldexp.c (fold_segment_align): When relro, don't adjust up by
            offset within page.  Set relropagesize.
            (fold_segment_relro_end): Align to relropagesize.
            * ldexp.h (seg_align_type): Rename pagesize to commonpagesize.
            Add relropagesize.  Comment.
            * ldlang.c (lang_size_segment): Adjust to suit field renaming.
            (lang_size_relro_segment_1): Align relro_end using relropagesize.

-- 
You are receiving this mail because:
You are on the CC list for the bug.