This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Encoding page size in the ELF header


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]