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: Rich Felker <dalias at libc dot org>, "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: 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: Mon, 28 Sep 2015 13:55:15 +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> <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> <20150927172456 dot GA10701 at redhat dot com> <20150927174100 dot GU17773 at brightrain dot aerifal dot cx>
On 09/27/2015 07:41 PM, Rich Felker wrote:
> There are several clean solutions, like putting the data in its own
> .so or allocating it at runtime with mmap rather than using static
> storage. But these all may defeat the intended security benefits since
> then you have to rely on a pointer to the data that's located
> somewhere that may be writable. The safest is probably the
> separate-.so approach with a pointer to it in const .data where it can
> be protected by relro.
I'm not sure if that solves anything. I don't think it's possible in
general just to set the .data section of a DSO to PROT_READ because the
implementation may have stored helper variables there which need
updating. What am I missing? I think the DSO has the same issues as
the main program.
--
Florian Weimer / Red Hat Product Security