[all-commits] [llvm/llvm-project] 5a58e9: [ELF] Align the end of PT_GNU_RELRO associated PT_...

[Fangrui Song via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5a58e98c2018f8cfea71e34e9717da40201a966b
      https://github.com/llvm/llvm-project/commit/5a58e98c2018f8cfea71e34e9717da40201a966b
  Author: Fangrui Song <i at maskray.me>
  Date:   2023-09-14 (Thu, 14 Sep 2023)

  Changed paths:
    M lld/ELF/Driver.cpp
    M lld/ELF/LinkerScript.cpp
    M lld/ELF/LinkerScript.h
    M lld/ELF/ScriptParser.cpp
    M lld/ELF/SyntheticSections.cpp
    M lld/ELF/SyntheticSections.h
    M lld/ELF/Writer.cpp
    M lld/docs/ELF/linker_script.rst
    M lld/docs/ReleaseNotes.rst
    M lld/test/ELF/arm-execute-only.s
    M lld/test/ELF/end-dso-defined.s
    A lld/test/ELF/linkerscript/data-segment-relro-ppc64.test
    M lld/test/ELF/linkerscript/data-segment-relro.test
    M lld/test/ELF/linkerscript/insert-before.test
    M lld/test/ELF/map-file-copy.s
    M lld/test/ELF/map-file.s
    M lld/test/ELF/partition-notes.s
    M lld/test/ELF/partition-synthetic-sections.s
    M lld/test/ELF/ppc64-section-layout.s
    M lld/test/ELF/relocation-copy-relro.s
    M lld/test/ELF/relro-bss.s
    M lld/test/ELF/relro-copyrel-bss-script.s
    M lld/test/ELF/relro.s
    M lld/test/ELF/riscv-section-layout.s
    M lld/test/ELF/section-name.s
    M lld/test/ELF/separate-segments.s
    M lld/test/ELF/shuffle-sections-init-fini.s
    M lld/test/ELF/shuffle-sections.s
    M lld/test/ELF/sort-norosegment.s
    M lld/test/ELF/x86-64-section-layout.s

  Log Message:
  -----------
  [ELF] Align the end of PT_GNU_RELRO associated PT_LOAD to a common-page-size boundary (#66042)

Close #57618: currently we align the end of PT_GNU_RELRO to a
common-page-size
boundary, but do not align the end of the associated PT_LOAD. This is
benign
when runtime_page_size >= common-page-size.

However, when runtime_page_size < common-page-size, it is possible that
`alignUp(end(PT_LOAD), page_size) < alignDown(end(PT_GNU_RELRO),
page_size)`.
In this case, rtld's mprotect call for PT_GNU_RELRO will apply to
unmapped
regions and lead to an error, e.g.

```
error while loading shared libraries: cannot apply additional memory protection after relocation: Cannot allocate memory
```

To fix the issue, add a padding section .relro_padding like mold, which
is contained in the PT_GNU_RELRO segment and the associated PT_LOAD
segment. The section also prevents strip from corrupting PT_LOAD program
headers.

.relro_padding has the largest `sortRank` among RELRO sections.
Therefore, it is naturally placed at the end of `PT_GNU_RELRO` segment
in the absence of `PHDRS`/`SECTIONS` commands.

In the presence of `SECTIONS` commands, we place .relro_padding
immediately before a symbol assignment using DATA_SEGMENT_RELRO_END (see
also https://reviews.llvm.org/D124656), if present.
DATA_SEGMENT_RELRO_END is changed to align to max-page-size instead of
common-page-size.

Some edge cases worth mentioning:

* ppc64-toc-addis-nop.s: when PHDRS is present, do not append
.relro_padding
* avoid-empty-program-headers.s: when the only RELRO section is .tbss,
it is not part of PT_LOAD segment, therefore we do not append
.relro_padding.

---

Close #65002: GNU ld from 2.39 onwards aligns the end of PT_GNU_RELRO to
a
max-page-size boundary (https://sourceware.org/PR28824) so that the last
page is
protected even if runtime_page_size > common-page-size.

In my opinion, losing protection for the last page when the runtime page
size is
larger than common-page-size is not really an issue. Double mapping a
page of up
to max-common-page for the protection could cause undesired VM waste.
Internally
we had users complaining about 2MiB max-page-size applying to shared
objects.

Therefore, the end of .relro_padding is padded to a common-page-size
boundary. Users who are really anxious can set common-page-size to match
their runtime page size.

---

17 tests need updating as there are lots of change detectors.