Re: ELF linking question related to symbol collisions

[Florian Weimer <fweimer at redhat dot com>]

On 12/18/2013 07:18 PM, Carlos O'Donell wrote:

> > Or more to the point, I'm not sure if the current linking algorithm
> > is what we need.  Something like -B direct might be a better fit for
> > our current needs.
>
> I assume we're talking about some of the features present in Solaris?

Correct.

> > Unless that function references static symbols, then it may or may
> > not be safe.  If everything ends up being interposed, it is okay, but
> > if not, code might hit different static symbols.
>
> That is correct. If the API has state then it would not work to use
> a mixed implementation as you point out.

It's also common to have code like this:

static const char * msg = "some string";

void
foo_close (struct foo *pfoo)
{
  if (pfoo->msg != msg)
    free (pfoo->msg);
  free (pfoo);
}

I think this is what sometimes break the Lua interpreter when interposed.

> > Sure, but I think static linking has no future.  If it reappears, it
> > will be in the form of LTO object files.
>
> Static has use cases that will never go away.
>
> I plan to support it in glibc forever or until some new method is
> as easy as static linking to solve the same use cases.

Yes, from a toolchain standpoint, it's absolutely true.  I was concerned 
with the distribution POV and didn't make that clear.

> I agree that toolchain features for managing namespaces are
> important.
>
> However, no amount of tooling will fix people from breaking
> the namespace. The tooling only helps you resolve the breakage.
>
> There must be a higher level analysis and policy at the distribution
> level.
>
> Do you disagree with that last statement?

I agree completely.  As a distribution, we also need some way to detect 
upstream surprises and override their decisions if necessary.

--
Florian Weimer / Red Hat Product Security Team