Re: gold linker 2.22 regressed for DragonFly [revised testsuite results]

[John Marino <dragonflybsd at marino dot st>]

On 1/6/2012 9:03 PM, John Marino wrote:
> On 1/6/2012 3:42 PM, Ian Lance Taylor wrote:
> > 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.


After many hours of digging into the issue, I might have an explanation 
for why the __bss_start and _edata symbols are getting assigned to the 
dynamic symbol table.  This is the only test that FreeBSD passes and 
DragonFly doesn't, and the reason for that wasn't clear.

Finally using --trace-symbol=__bss_start might have provided a clue.  It 
said __bss_start was defined in libc.so, libm.so, and libstdc++.so.  My 
guess is that the presence of the symbols in those libraries caused gold 
to promote the __bss_start symbol to global.

As for why FreeBSD doesn't have these symbols in their system libraries, 
the difference might be in their use of symbol version maps. 
Unfortunately DragonFly doesn't yet version their library functions, so 
the lack of version scripts means every library has this symbol.

Am I on the right track in diagnosing this test failure?


> > > > > 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.




I started working to support this.  It also requires new code for crt1 
to handle the main executable.  It's going to take some more work to 
implement this completely.




> > > > > 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


I came up with an initial implementation of relro for the dynamic linker 
and FreeBSD's Konstantin Belousov reviewed and added to it.  Now 
DragonFly passes these three tests and I think there's a good chance 
that code will get incorporated into FreeBSD as well.

John