[Gluster-users] booster

Mark Mielke mark at mark.mielke.cc
Mon Sep 14 14:17:59 UTC 2009


On 09/14/2009 06:31 AM, Stephan von Krawczynski wrote:
>> 2. running bash wasnt a very useful scenario when the LD_PRELOAD
>> variable can be added for the bash environment as a whole. For eg.
>> if you just do "export LD_PRELOAD=<blah>" on the command line, you can
>> actually have every program started from that shell use booster.
>>
>> -Shehjar
>>      
> There is a problem with that: if your bash environment calls only one other
> bash-script it will fail either. Another problem can be script-replaced
> binaries. If you replace some classical binary with a shell-script for
> additional parameters (or any other thinkable reason) this general export
> approach will fail, too.
> Or lets say your favourite email client calls some script to mark spam...
> There are a lot of black holes in this ground ...
>    

I'm pretty sure it's related to a previous thread I started - booster 
does not require glibc to be compiled with --no-hidden-plt. This means 
that any functions glibc runs that execute *other* system calls, such as 
fopen() calling open(), do not get intercepted, on modern Linux 
distributions. This would be a huge problem for most applications as 
STDIO is more common than not. (There are probably other system calls 
not intercepted as well)

Booster may work fine for applications that are designed for 
performance, that avoid the STDIO layer, and stick to common "system 
calls" such as open(), read(), write(), fsync(), close(). Bash is 
probably not one of these.

For hidden PLT, because I think people didn't understand what I was 
talking about in the previous thread and I let it go - GLIBC 
purposefully uses a "hidden PLT", such that any time GLIBC calls open() 
from within itself, it will normally use it's OWN version, even if 
open() is overridden using a scheme such as LD_PRELOAD. The two main 
arguments for this are: 1) Reduce chance of LD_PRELOAD screwing GLIBC 
up, and 2) Slightly better performance. Solutions such as LUFS and 
several others including our home grown solution, require GLIBC to be 
built with --no-hidden-plt to disable this feature, and allow override 
of open() to affect GLIBC's use of open(), such as fopen() calling open().

Cheers,
mark

-- 
Mark Mielke<mark at mielke.cc>




More information about the Gluster-users mailing list