Re: Fix relro when COMMONPAGESIZE < MAXPAGESIZE

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Sep 08, 2004 at 12:34:11AM +0200, Andreas Schwab wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > On Thu, Sep 02, 2004 at 05:39:34PM +0200, Andreas Schwab wrote:
> >> Adjusting the relro end address during DATA_SEGMENT_ALIGN throws aways any
> >> previous data segment alignment, causing the resulting binary to contain a
> >> big hole.
> >
> > Can you post readelf -WS output before and after the patch?
> > The big hole was certainly intended there, so that MAXPAGESIZE is properly
> > honored.
> 
> The big hole had nearly MAXPAGESIZE bytes, which is surely not intented
> (especially when text size is much smaller than that).
> 
> Here's the text/data boundary:
> 
>   [18] .eh_frame         PROGBITS        00000000000088e8 0088e8 000cac 00   A  0   0  8
>   [19] .ctors            PROGBITS        000000000010a370 00a370 000010 00  WA  0   0  8
> 
> Without the patch section .ctors is placed at 0x100ddc, giving a wastage
> of 1010284 bytes in the file, which is more than 26 times the text segment
> size.

The file is sparse.
And, if you change 0x100ddc to 0x10a370, then I'm very sure .got.plt + 24
is not at 4K boundary if it was on 4K boundary with 0x100ddc.
So, the user requested -z relro, but your patch makes the protection
impossible.  -z relro is there for security reasons and is off by default.
If you turn it on, you are prepared to pay the price that you have a sparse
file or if you don't have sparse files, it eats more disk space.

	Jakub