[ELF] Align the end of PT_GNU_RELRO to max-page-size instead of common-page-size

[MaskRay]

Summary

We picked common-page-size to match GNU ld. Recently, the resolution to GNU ld
https://sourceware.org/bugzilla/show_bug.cgi?id=28824 (milestone: 2.39) switched
to max-page-size so that the last page can be protected by RELRO in case the
system page size is larger than common-page-size.

Thanks to our two RW PT_LOAD scheme (D58892), switching to max-page-size does
not change file size (while GNU ld's scheme may increase file size).

[peter.smith]

LGTM thanks for making the change. It was useful to see the write up in the binutils PR as common page versus max page size isn't documented very well.

[MaskRay]

add release note

[nathanchance]

I am seeing a failure during a two stage build of LLVM on an AArch64 host that I bisected to this change:

[3118/3661] ASTNodeAPI.json

FAILED: tools/clang/lib/Tooling/ASTNodeAPI.json …
…/bin/clang-ast-dump: error while loading shared libraries: cannot apply additional memory protection after relocation: Cannot allocate memory

What information would be helpful for investigating what is going on?

[MaskRay]

I somehow forgot that we can not simply round up the end of PT_GNU_RELRO to max-page-size.

I think this is a limitation of our 2 RW PT_LOAD scheme and we may have to expect that if system page size is larger than common-page-size, the last partial page may not be protected by RELRO.
See also https://reviews.freebsd.org/D31498 that system page size smaller than common-page-size may have problems as well.

[MaskRay]

This is superseded by https://github.com/llvm/llvm-project/pull/66042 . I've mentioned there why runtime_page_size < common-page-size may lead to glibc rtld error while loading shared libraries: cannot apply additional memory protection after relocation: Cannot allocate memory.
If we simply change common-page-size to max-page-size on the p->p_memsz line, this condition would be runtime_page_size < max-page-size .
When max-page-size is 64KiB (ARM/AArch64/PowerPC) and runtime page-size is typically smaller (4KiB), error while loading shared libraries: cannot apply additional memory protection after relocation: Cannot allocate memory will almost assuredly occur.

lld/ELF/Writer.cpp

if (first) {
         p->p_offset -= part.elfHeader->getParent()->offset;
 
       if (!p->hasLMA)
         p->p_paddr = first->getLMA();
     }
 
     if (p->p_type == PT_GNU_RELRO) {
       p->p_align = 1;
-      // musl/glibc ld.so rounds the size down, so we need to round up
-      // to protect the last page. This is a no-op on FreeBSD which always
-      // rounds up.
-      p->p_memsz = alignTo(p->p_offset + p->p_memsz, config->commonPageSize) -
-                   p->p_offset;
+      // musl/glibc/FreeBSD ld.so rounds the size down, so we need to round up
+      // to protect the last page.
+      p->p_memsz =
+          alignTo(p->p_offset + p->p_memsz, config->maxPageSize) - p->p_offset;
     }
   }
 }
 
 // A helper struct for checkSectionOverlap.
 namespace {
 struct SectionOffset {
   OutputSection *sec;

lld/test/ELF/aarch64-relro.s

 # REQUIRES: aarch64
 # RUN: llvm-mc -filetype=obj -triple=aarch64-unknown-freebsd %s -o %t
 # RUN: ld.lld %t -o %t2
 # RUN: llvm-readobj -l %t2 | FileCheck %s
 
 # CHECK:      Type: PT_GNU_RELRO
 # CHECK-NEXT: Offset:
 # CHECK-NEXT: VirtualAddress: 0x220190
 # CHECK-NEXT: PhysicalAddress:
 # CHECK-NEXT: FileSize:
-# CHECK-NEXT: MemSize: 3696
+# CHECK-NEXT: MemSize: 65136
 
 .section .data.rel.ro,"aw",%progbits
 .byte 1

lld/test/ELF/basic-ppc64.s

 // CHECK-NEXT:    Alignment: 8
 // CHECK-NEXT:  }
 // CHECK-NEXT:  ProgramHeader {
 // CHECK-NEXT:    Type: PT_GNU_RELRO (0x6474E552)
 // CHECK-NEXT:    Offset: 0x238
 // CHECK-NEXT:    VirtualAddress: 0x20238
 // CHECK-NEXT:    PhysicalAddress: 0x20238
 // CHECK-NEXT:    FileSize: 96
-// CHECK-NEXT:    MemSize: 3528
+// CHECK-NEXT:    MemSize: 64968
 // CHECK-NEXT:    Flags [ (0x4)
 // CHECK-NEXT:      PF_R (0x4)
 // CHECK-NEXT:    ]
 // CHECK-NEXT:    Alignment: 1
 // CHECK-NEXT:  }
 // CHECK-NEXT:  ProgramHeader {
 // CHECK-NEXT:    Type: PT_GNU_STACK (0x6474E551)
 // CHECK-NEXT:    Offset: 0x0