Encoding page size in the ELF header
Rich Felker
dalias@libc.org
Sun Sep 27 17:12:00 GMT 2015
On Sun, Sep 27, 2015 at 11:02:42AM +0200, Florian Weimer wrote:
> On 09/27/2015 10:55 AM, Andreas Schwab wrote:
> > Rich Felker <dalias@libc.org> writes:
> >
> >> On Sat, Sep 26, 2015 at 07:13:00PM -0400, Frank Ch. Eigler wrote:
>
> >>> Could the app more portably use
> >>>
> >>> int critical_data __attribute__((section(".data.critical")));
> >>>
> >>> and maybe a linker script widgetry to assure padding & fetch
> >>> base-addresses, and then mprotect it that way? It would become
> >>> independent of page size.
> >>
> >> That does not eliminate the page size dependency.
> >
> > MAXPAGESIZE is available in the linker script.
>
> But ld.so supports running binaries with a larger kernel page size than
> MAXPAGESIZE, don't we? In most cases, it does work, after all.
No; this is fundamentally impossible unless you want to throw away
mmap and use 'memcpy'/'read' to load executables. The definition of
"page size" (from an application/user perspective; this may differ
from hardware in some cases) is simply mmap granularity.
To see why, suppose I have the following PT_LOAD segments:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x84cc4 0x84cc4 R E 0x1000
LOAD 0x085000 0x00085000 0x00085000 0x00458 0x0240c RW 0x1000
Since this is normal ELF (not FDPIC), the displacement between
segments is fixed; this is necessary in order for PC-relative
addressing (to obtain the GOT address or PC-relative data addresses)
to work. The second LOAD segment needs to be placed at an offset of
0x85000 from the first. But the largest power of 2 to which 0x85000 is
aligned is 0x1000 (4k); 0x85000 mod 0x2000 is 0x1000. Thus it's
impossible for both load segments to be simultaneously aligned mod
0x2000 or any larger power of two.
Hardware platforms that actually _need_ different page sizes for
different cpu/mmu models (i.e. MIPS) _must_ use a higher LOAD segment
alignment (=MAXPAGESIZE) in their program headers.
Rich
More information about the Libc-alpha
mailing list