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: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, Andreas Schwab <schwab at linux-m68k dot org>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 27 Sep 2015 13:24:56 -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> <20150927171224 dot GT17773 at brightrain dot aerifal dot cx>
Hi -
> > >>> Could the app more portably use
> > >>> int critical_data __attribute__((section(".data.critical")));
> > >>> and maybe a linker script widgetry to assure padding [...]
> [...]
> 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
> [...] 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.
An application that wishes to protect itself against larger page
sizes, but still play page-protection tricks, can include pessimistic
padding (ahead and/or behind) for its mprotecty sections, basically
hard-coding a maximum acceptable page size. If the data protection
with current tooling is that important, they can probably afford even
a 1MB page full of padding/alignment.
- FChE