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: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 25 Sep 2015 21:29:08 +0200
- 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>
On 09/25/2015 09:17 PM, Carlos O'Donell wrote:
> On 09/25/2015 09:04 AM, Florian Weimer wrote:
>> Not sure if this the right mailing list for this discussion.
>>
>> I think we should record the expected page size in the ELF header in
>> some way. It affects the behavior of the static linker, the dynamic
>> linker, and even some applications. (For example, an application might
>> want to make a part of .data read-only after initialization, as a
>> hardening measure.)
>>
>> What would be a good way to do that?
>
> 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.
This fails if the page size is suddenly 64 KiB. I don't know how common
this is, but it does make the binary dependent on page size (similar to
RELRO, but we transparently disable RELRO if that happens).
Allocating a new page would mean that you must have a pointer to the
page somewhere, which you need to protect in the same way, so it doesn't
solve the problem.
--
Florian Weimer / Red Hat Product Security