Date: Sun, 25 May 2003 22:31:20 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "Matthew N. Dodd" <mdodd@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. Message-ID: <20030526053120.GB1941@athlon.pn.xcllnt.net> In-Reply-To: <20030525202140.Y86964@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> <xzpaddb8ab8.fsf@flood.ping.uio.no> <20030525084629.R30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> <20030525190744.A86964@sasami.jurai.net> <20030526001924.GA1272@athlon.pn.xcllnt.net> <20030525202140.Y86964@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030526053120.GB1941>