Re: Preliminary ELF prebinding patches available.

On Sun, May 25, 2003 at 08:33:31PM -0400, Matthew N. Dodd wrote:
> On Sun, 25 May 2003, Marcel Moolenaar wrote:
> > > I was more concerned with simplicity; the method I use solves the problem
> > > with minimal effort and complexity.  The combination of time() + random()
> > > + filename will not collide on a single box.
> >
> > But it can across NFS, right?
> 
> Uh...  If you want to share /var/db/prebind via NFS I suppose you can.

I was more thinking about having executables shared across machines,
but it's not unthinkable to share prebind information.

> I'm not sure how a practical NFS environment would result in a greater
> chance of collisions.  Regardless, there is no real penalty for collisions
> (other than prebinding not being available for that executable.)

Precisely. This links us back to my observation that collisions didn't
appear to be handled well enough. Not being able to have prebinding
for some executable because there's a name collision is what I call
"not well enough".

> > > I'll be adding a platform identifier to the file header.  All I'm
> > > concerned with is being able to reject a file if its not for the current
> > > platform.  I have no expectation of cross-generating prebinding files.
> >
> > Please keep that option open. Not only do we have to deal with byte-
> > order on a single platform, we also have to keep an eye on emulation
> > layers (ia32 on ia64 and ia32 on amd64).
> 
> Its simply not possible to cross-generate prebinding files.  Period.

If you can cross-generate executables (by means of a cross-compiler,
cross-assembler and cross-linker), then I don't see why you cannot
cross-generate binding information (by means of a cross-prebinder).

But before we miss the point: leaving the option open does not mean
that you have to do it, just that you avoid making it impossible by
not defining file layouts carefully enough. It also doesn't mean that
you have to have the possibility against all odds.

> (You're of course welcome to implement a totally standalone utility that
> duplicates much of the functionality that rtld-elf provides.)

Aren't we all welcome in that respect? :-)

> > Decoupling the program from its prebinding information can create all
> > sorts of nasty (ie unexpected) complexities.
> 
> Uh, what?  I'm not parsing this.

The prebinding information lives under /var/db/prebind, right?
I don't think we normally put our executables there as well and
if we do, we don't have the prebind information *in* the executable.
Hence, prebind information is decoupled from the executable. One
of the more obvious complexities is the fact that the naming scheme
is such that multiple binaries can have the same prebind cache file.
The collision is currently not handled, other than making sure that
the prebind information for binary A1 is not used by binary A2. But
other complexities exist. What if by some unlucky draw of faith you
have two totally independent executables that both resolve to the
same prebind file *and* happen to have the same build ID? You have
an undetectable collision.

Before this point starts a whole argument of it's own: you already
said that you wanted something simple to implement, so let it be
noted that if you're at a point where you can productize this, you
have to make sure that you have a good way to deal with it or
otherwise clearly state somewhere why not.

> > What are the major reasons for not editing the executable in your
> > opinion?
> 
> Besides it not working?

I don't see why it cannot work. You have to explain to me why you
cannot edit an executable. It may not be common, but it's done
(HP-UX has chatr of example).

> It is not possible for rtld-elf to access
> the section header, let alone additional section data in a clean manner.

It cannot be any more unclean than the ELF headers, segments and other
data like the symbol table or relocation information are being accessed
now, can't it?

> Furthermore, rtld-elf is not provided with a valid file handle for the
> main executable so hacks to access section data of libraries won't
> actually work for the main executable.

This is something the OS can provide by means of the AUXARGS. We already
tell rtld where the base of the executable is (AFAICT), so we have a
valid ELF header right at our fingertips. You don't need more.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net