5a58e98c20
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.
62 lines
2.2 KiB
ArmAsm
62 lines
2.2 KiB
ArmAsm
# REQUIRES: x86
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
|
|
|
|
# RUN: ld.lld -z norelro %t.o -o %t
|
|
# RUN: llvm-readelf -x .init -x .fini -x .init_array -x .fini_array %t | \
|
|
# RUN: FileCheck --check-prefixes=CHECK,ORDERED %s
|
|
|
|
# RUN: ld.lld -z norelro %t.o --shuffle-sections '*=1' -o %t1
|
|
# RUN: llvm-readelf -x .init -x .fini -x .init_array -x .fini_array %t1 | \
|
|
# RUN: FileCheck --check-prefixes=CHECK,SHUFFLED %s
|
|
|
|
## .init and .fini rely on a particular order, e.g. crti.o crtbegin.o crtend.o crtn.o
|
|
## Don't shuffle them.
|
|
# CHECK: Hex dump of section '.init'
|
|
# CHECK-NEXT: 00010203 04050607 08090a0b
|
|
|
|
# CHECK: Hex dump of section '.fini'
|
|
# CHECK-NEXT: 00010203 04050607 08090a0b
|
|
|
|
## SHT_INIT_ARRAY/SHT_FINI_ARRAY with explicit priorities are still ordered.
|
|
# CHECK: Hex dump of section '.init_array'
|
|
# CHECK-NEXT: 0x{{[0-9a-f]+}} ff
|
|
# ORDERED-SAME: 000102 03040506 0708090a 0b
|
|
# SHUFFLED-SAME: 070201 0006090a 040b0503 08
|
|
|
|
# CHECK: Hex dump of section '.fini_array'
|
|
# CHECK-NEXT: 0x{{[0-9a-f]+}} ff
|
|
# ORDERED-SAME: 000102 03040506 0708090a 0b
|
|
# SHUFFLED-SAME: 070008 0a040209 03010b06 05
|
|
|
|
## With a SECTIONS command, SHT_INIT_ARRAY prirotities are ignored.
|
|
## All .init_array* are shuffled together.
|
|
# RUN: echo 'SECTIONS { \
|
|
# RUN: .init_array : { *(.init_array*) } \
|
|
# RUN: .fini_array : { *(.fini_array*) }}' > %t.script
|
|
# RUN: ld.lld -T %t.script %t.o -o %t2
|
|
# RUN: llvm-readelf -x .init -x .fini -x .init_array -x .fini_array %t2 | \
|
|
# RUN: FileCheck --check-prefixes=CHECK2,ORDERED2 %s
|
|
# RUN: ld.lld -T %t.script %t.o --shuffle-sections '*=1' -o %t3
|
|
# RUN: llvm-readelf -x .init -x .fini -x .init_array -x .fini_array %t3 | \
|
|
# RUN: FileCheck --check-prefixes=CHECK2,SHUFFLED2 %s
|
|
|
|
# CHECK2: Hex dump of section '.init_array'
|
|
# ORDERED2-NEXT: 0x{{[0-9a-f]+}} 00010203 04050607 08090a0b ff
|
|
# SHUFFLED2-NEXT: 0x{{[0-9a-f]+}} 07020100 06090a04 0b050308 ff
|
|
|
|
.irp i,0,1,2,3,4,5,6,7,8,9,10,11
|
|
.section .init,"ax",@progbits,unique,\i
|
|
.byte \i
|
|
.section .fini,"ax",@progbits,unique,\i
|
|
.byte \i
|
|
.section .init_array,"aw",@init_array,unique,\i
|
|
.byte \i
|
|
.section .fini_array,"aw",@fini_array,unique,\i
|
|
.byte \i
|
|
.endr
|
|
|
|
.section .init_array.1,"aw",@init_array
|
|
.byte 255
|
|
.section .fini_array.1,"aw",@fini_array
|
|
.byte 255
|