gold linker 2.22 regressed for DragonFly [revised testsuite results]

[Ian Lance Taylor]

John Marino <binutils@marino.st> writes:

> On 1/5/2012 7:31 PM, Ian Lance Taylor wrote:
>>> 2. ver_matching_test.sh:  __bss_start not local, rtld issue? real issue? (failed on v2.21 too)
>>
>> Hard to understand why this would fail.  The __bss_start symbol is
>> defined automatically by the linker itself.
>
> ok.  I thought I remembered seeing references to __bss_start in rtld
> code, so I suspected rtld was the culprit.

Ideally rtld should not have a publically visible definition of
__bss_start, but I don't see how it would cause a test failure even if
it did.


>>> 3. exception_static_test: likely real problem.  gdb log attached
>>
>> My first guess would be that DragonFly does not support dl_iterate_phdr,
>> or that it does not work correctly for statically linked executables.
>> That's just a guess, though.
>
> I brought in dl_iterate_phdr support to dragonfly (system compiler is
> 4.4.7 snapshot, 2011-10-25), and it appears to be working although
> maybe in the case of statically linked executables it's not.  What
> handles the latter?  Is that an rtld thing?

Statically linked executables don't use rtld at all.  They need to use a
completely different mechanism to get the program segments, typically
just the single set associated with the executable itself.  On GNU/Linux
systems the kernel passes the program segments in the auxiliary vector
using AT_PHDR and AT_PHNUM, and the startup code saves those for use by
dl_iterate_phdr in a static executable.


>>> 4. intpri2:               likely real problem.  gdb log attached
>>
>> This is almost certainly the same issue as the --no-ctors-in-init-array
>> issue: DragonFly does not suppor DT_INIT_ARRAY.
>
> If I wanted to add DT_INIT_ARRAY support to DragonFly, what component
> needs to be updated?  again rtld?

Yes.  Also you need to do some magic for statically linked executables,
taking advantage of the linker-defined symbols __init_array_start and
__init_array_end and friends.


>>> 5. relro_test:            no relro support in rtld, ignore
>>> 6. relro_now_test:        no relro support in rtld, ignore
>>> 7. relro_strip_test:      no relro support in rtld, ignore
>>
>> Yeah, if the dynamic linker does not handle relro, then these tests are
>> expected to fail.
>
> As far as I can tell, no BSD supports relro and it seems to be of
> limited value so I don't suspect this will change any time soon.

I'm surprised that no BSD supports relro as it is a security
enhancement.  I agree that the value is limited but it is not zero.

In my opinion, the biggest advantage is for the PLT.  The PLT must often
be writable when the program starts, so that dynamic relocations can be
applied.  The PLT holds code addresses, so this gives various sorts of
overflow attacks a way to change which code will execute, by overwriting
the PLT.

The point of relro is that after all the PLT relocations have been
applied, there is no need for the PLT to change again.  Making the PLT
be relro implements that: the dynamic linker applies the relocations,
then uses mprotect to make the PLT readonly.

This does of course require that the PLT be fully relocated at program
startup time, rather than using lazy PLT relocations which is the
default behaviour.  You can use the linker option -z now to request that
all PLT relocations be fully relocated at program startup, and when gold
sees -z now it will make the PLT a relro section.

Ian