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: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Florian Weimer <fweimer 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 01:25:23 -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>
On Sat, Sep 26, 2015 at 07:13:00PM -0400, Frank Ch. Eigler wrote:
>
> fweimer wrote:
>
> > [...]
> >> Can't the application just call getpagesize(), and then use that to
> >> decide how to make .data read-only?
> >
> > The idea is to do something like this:
> > #define PAGE_SIZE 4096
> > union {
> > int critical_data;
> > char pad[PAGE_SIZE];
> > } u __attribute__((aligned(PAGE_SIZE))) = {};
> >
> > And then call mprotect(&u, PAGE_SIZE, PROT_READ) after initialization.
>
> 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.
Rich