Re: PATCH: Increase the size of .data.rel section for -z relro check

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jul 12, 2011 at 07:45:32PM -0700, H.J. Lu wrote:
> On Tue, Jul 12, 2011 at 7:27 PM, Roland McGrath <roland@hack.frob.com> wrote:
> > This seems to me like a bona fide bug in ld.
> >
> > It doesn't produce a PT_GNU_RELRO at all when there is a .data.rel.ro and
> > -z relro and so clearly it should. ?Yet when there is no .data.rel.ro and
> > only a .data.rel (and -z relro), it produces a PT_GNU_RELRO covering
> > nothing by .dynamic (which is correct).
> >
> > The ld implementation relating to relro is rather byzantine and I haven't
> > made any sense of it so far. ?Perhaps someone like you or Andreas who knows
> > the ld code better could figure out what's going on.
> >
> 
> Jakub, do you know how relro should work in this case?

I'd say it is the fault of the artificial testcase.
The problem is that in the writable PT_LOAD
there are just the two to be relro sections (.data.rel.ro and .dynamic)
and no other sections afterwards, and due to alignment requirements the
RW PT_LOAD is actually smaller than PT_GNU_RELRO would need to be, which
violates the PT_GNU_RELRO requirements that PT_GNU_RELRO is just a portion
of some PT_LOAD.
In particular, ld decided to place .data.rel.ro at
0x200ef0 and has size 0x18 and .dynamic at 0x200f08 and size 0xe0.
The reason why the .data.rel.ro doesn't start at 0x200ef8 is that
it has .align 16.  PT_GNU_RELRO needs to end at common page size boundary,
so PT_GNU_RELRO 0x200ef0 ... 0x201000 wouldn't be part of the
0x200ef0 ... 0x200ff8 PT_LOAD.  Obviously, if you have any non-empty
writable section afterwards (.data etc.), it will work just fine as the
linker can insert padding in between the .dynamic section and that following
section.

So I'd say, just adjust the configure test to include some writable data
section, even if it is just a single byte.  I very much doubt any shared
library or binary that does something useful will suffer from this.

	Jakub