Fix relro when COMMONPAGESIZE < MAXPAGESIZE

Daniel Jacobowitz drow@false.org
Wed Sep 8 13:14:00 GMT 2004


On Wed, Sep 08, 2004 at 06:36:00AM -0400, Jakub Jelinek wrote:
> On Wed, Sep 08, 2004 at 12:09:49PM +0200, Andreas Schwab wrote:
> > Jakub Jelinek <jakub@redhat.com> writes:
> > 
> > > 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.
> > 
> > Then the relro adjustment calculation is broken.  It does not make sense
> > to waste 1MB in a 120K object just to get 4K alignment.
> 
> So, can you suggest a better solution?
> The constraints are:
> 1) for all segments, (p_vaddr % MAXPAGESIZE) == (p_offset % MAXPAGESIZE)
>    This is because the ELF object ought to be usable on systems with
>    MAXPAGESIZE page size.
> 2) so that the PT_GNU_RELRO region can be successfully protected
>    when system page size <= COMMONPAGESIZE, PT_GNU_RELRO's end must be
>    COMMONPAGESIZE aligned.  For system page size > COMMONPAGESIZE the
>    library/binary shall be usable, but no protection will work.

I haven't followed very closely, but why does this imply a hole in the
file?  For instance:
  ro segment:	 vaddr 0x00000000 offset 0x00000000 size 0x00000f00
  relro segment: vaddr 0x00011000 offset 0x00001000 size 0x00000f00

There, p_vaddr % 0x00010000 == 0x00001000, and they're on different 4k
pages.  You waste some memory if pagesize > COMMONPAGESIZE which is
exctly as expected.  You never waste more than COMMONPAGESIZE between
segments in the binary, exactly as for other segments.

-- 
Daniel Jacobowitz



More information about the Binutils mailing list