[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/28824] New: relro security issues
From: |
amodra at gmail dot com |
Subject: |
[Bug ld/28824] New: relro security issues |
Date: |
Thu, 27 Jan 2022 00:21:10 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Bug ID: 28824
Summary: relro security issues
Product: binutils
Version: 2.38
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amodra at gmail dot com
Target Milestone: ---
powerpc64le-linux often runs with 64k memory pages, which is the default
maxpagesize for this target. The end of the PT_GNU_RELRO segment is only
aligned to commonpagesize (4k for powerpc64le-linux). These two facts can
result in up to 60k at the end of the relro segment not being write-protected.
Other targets behave similarly.
How did we get to this situation?
I believe the fundamental underlying issue is that the x86 linker treats
maxpagesize differently to its original intent, which is to lay out a binary
for hardware paging of up to maxpagesize. On x86, hardware paging is always
the commonpagesize of 4k. So on x86 a maxpagesize larger than 4k is merely for
memory optimisation, and aligning the end of the relro segment to
commonpagesize makes sense. Unfortunately, that's wrong for practically every
other target.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/28824] New: relro security issues,
amodra at gmail dot com <=