summaryrefslogtreecommitdiff
path: root/ld/ldlang.c
diff options
context:
space:
mode:
authorAlan Modra <amodra@gmail.com>2022-01-27 15:17:16 +1030
committerAlan Modra <amodra@gmail.com>2022-02-13 14:00:56 +1030
commit9833b7757d246f22db4eb24b8e5db7eb5e05b6d9 (patch)
treeb35cae2b1d24043f67809583e89d7c9550abce21 /ld/ldlang.c
parentf63300e0fae2c114186e1985ecbe5641e05c13c3 (diff)
downloadbinutils-gdb-9833b7757d246f22db4eb24b8e5db7eb5e05b6d9.tar.gz
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.
Diffstat (limited to 'ld/ldlang.c')
-rw-r--r--ld/ldlang.c13
1 files changed, 6 insertions, 7 deletions
diff --git a/ld/ldlang.c b/ld/ldlang.c
index 84511c4d615..f481586a7ba 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -6352,12 +6352,12 @@ lang_size_segment (seg_align_type *seg)
a page could be saved in the data segment. */
bfd_vma first, last;
- first = -seg->base & (seg->pagesize - 1);
- last = seg->end & (seg->pagesize - 1);
+ first = -seg->base & (seg->commonpagesize - 1);
+ last = seg->end & (seg->commonpagesize - 1);
if (first && last
- && ((seg->base & ~(seg->pagesize - 1))
- != (seg->end & ~(seg->pagesize - 1)))
- && first + last <= seg->pagesize)
+ && ((seg->base & ~(seg->commonpagesize - 1))
+ != (seg->end & ~(seg->commonpagesize - 1)))
+ && first + last <= seg->commonpagesize)
{
seg->phase = exp_seg_adjust;
return true;
@@ -6374,8 +6374,7 @@ lang_size_relro_segment_1 (seg_align_type *seg)
asection *sec;
/* Compute the expected PT_GNU_RELRO/PT_LOAD segment end. */
- relro_end = ((seg->relro_end + seg->pagesize - 1)
- & ~(seg->pagesize - 1));
+ relro_end = (seg->relro_end + seg->relropagesize - 1) & -seg->relropagesize;
/* Adjust by the offset arg of XXX_SEGMENT_RELRO_END. */
desired_end = relro_end - seg->relro_offset;