[RFC PATCH] Little hardening DSOs/executables against exploits (take 2)

[Jakub Jelinek]

On Fri, Jan 16, 2004 at 08:08:54AM +1030, Alan Modra wrote:
> On Thu, Jan 15, 2004 at 12:29:39PM +0100, Jakub Jelinek wrote:
> > That's because the order of .got/.sbss/.data/.sdata/.bss should be following:
> > 
> > RW segment small:
> > ----------+
> > .got      |
> > RELRO_END |
> > .data     |- reachable by pic reg
> > .sdata    |
> > .sbss-----+
> > .bss
> 
> Ah, I missed noticing that you were putting .data in the middle of
> .got / .sdata in one case.
> 
> > SBSS small:
> > .got------+
> > RELRO_END |
> > .sdata    |- reachable by pic reg
> > .sbss-----+
> > .data
> > .bss
> 
> Here, the real condition isn't that .sbss is small, but that the
> combined size of .got, .sdata, .sbss and the segment gap you
> introduce is less than 32k.  Can you manage to test something like that?

There is no segment gap.  RELRO_END doesn't advance dot at all, ld just
tries to align that dot on a (common) page boundary by increasing/decreasing
the gap between PT_LOAD segments.
If .got/.sdata/.sbss together don't fit into arch reachability limit from
pic pointer (32k or perhaps 64k on ppc32, but similar handling is needed
for alpha/ia64/ppc64/...), then linking will fail.
The condition is "SBSS small" so that it doesn't hurt when .sbss becomes
SHT_PROGBITS instead of SHT_NOBITS (because it is before .data section).
If .sbss was 30k, the options would be either to create 3 PT_LOAD segments
which slows everything down, or back up all of .sbss in the file, or
give up and put .got above .data.

> Also, the 32k limit might change some time as the ABI allows you to put
> _GLOBAL_OFFSET_TABLE in the middle of .got.

If that constant is written in the linker script, it can be easily tweaked
in emulparams.

	Jakub