This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Encoding page size in the ELF header
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, "Frank Ch. Eigler" <fche at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 27 Sep 2015 13:12:24 -0400
- Subject: Re: Encoding page size in the ELF header
- Authentication-results: sourceware.org; auth=none
- References: <56054662 dot 2010106 at redhat dot com> <56059DD4 dot 1080908 at redhat dot com> <5605A084 dot 4010501 at redhat dot com> <y0mtwqgwz9f dot fsf at fche dot csb> <20150927052523 dot GP17773 at brightrain dot aerifal dot cx> <m2si60tf6e dot fsf at linux-m68k dot org> <5607B0B2 dot 2010906 at redhat dot com>
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