Subject: Re: New idea on ELF prebinding
To: Robert Elz <kre@munnari.OZ.AU>
From: Bang Jun-Young <email@example.com>
Date: 11/23/2002 14:29:07
On Fri, Nov 22, 2002 at 08:52:40PM +1100, Robert Elz wrote:
> Date: Fri, 22 Nov 2002 09:27:40 +0100
> From: Martin Husemann <firstname.lastname@example.org>
> Message-ID: <20021122082740.GD416@drowsy.duskware.de>
> | Only one file,
> Which means the file is altered, which means that you can no longer easily
> check that the file you're running is identical with the distribution copy.
> I much prefer the "file on the side" method, provided the file goes in /var
> and not /usr (/usr is, or should be able to be, read only - I mount it that
> way all the time, and would prefer to avoid even more null mounts to provide
> the few odd necessary writable pieces - currently all required by X).
I like both, but some people don't like "file on the side" method for
security reasons. I'll be back with the subject "Why security doesn't matter"
sooner or later. ;-)
> Jun-Yong ...
> | My proposal is also completely optional.
> per file (executable) or just on/off big switch? I'd prefer the former.
> That is, the vast majority of programs aren't run enough, and don't cost
> enough to dynamically link, that it really isn't worth the effort dealing
> with them. I'd like to just turn on this cache for the few files that are
> used enough,a nd cost enough, that there would be a real gain. If it is
> per file, how is it controlled?
Per-file switch can be implemented by filling .cksum (renamed from .csum
for consitency with the name of cksum(1)) with FFFFFF..FFFFFF. System-wide
switch still can be turned on/off by setting/unsetting LD_PREBIND
> I had a half thought out idea of something similar, but just keeping the
> linked binary in swap space (in virtual memory) so it would be re-bound once,
> at least, each boot (and perhaps more often, using weighted LRU (weighted by
> size) to discard bindings and avoid using too much VM) which I had expected
> might be controlled by the 't' bit on the executable (with that being passed
> to ld.elf_so - and it telling the kernel to preserve a copy of the image,
> by making all pages copy on write, keeping the original untouched, in a
> cache, ready for next time - if the kernel found such a thing in this new
> cache, it would just skip ld.elf_so completely, and run the copy instead).
A kind of "hibernation"?
Bang Jun-Young <email@example.com>