This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: Fix relro when COMMONPAGESIZE < MAXPAGESIZE


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


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