ld.so.preload of libmediaclient.so is *very* harmful

[Markus Rechberger]

Andrew Bartlett <abartlet <at> samba.org> writes:

> 
> On Fri, 2011-02-04 at 04:39 +0000, Markus Rechberger wrote:
> > Andrew Bartlett <abartlet <at> samba.org> writes:
> > 
> > > 
> > > On Thu, 2011-02-03 at 13:28 +0100, c.hoffmann <at> bnet.at wrote:
> > > > Could finish provision!
> > > > There was a problem with the libmediaclient.so which is installed with 
the
> > > > driver for my tv-card (sundtek) I am using.
> > > > Deinstalled the driver and did provision again, this time it worked!
> > > > Reinstall the driver and it hopefully does not interfere with samba4.
> > > > 
> > > > br
> > > 
> > > After a very good guess by tridge, I found:
> > > http://www.sundtek.com/support/install.sh.txt
> > > 
> > > This script, which I presume you used, modifies /etc/ld.so.preload, and
> > > causes libmediaclient.so to be preloaded into every single process on
> > > the system.  Any process that calls net_read() will call into your TV
> > > card driver, and will break badly.
> 
> > As we had the discussion, this discussion came up in our forums as well, the 
> > problem is some users are not very familiar with the console and that's the 
> > reason why it is set globally. 
> 
> Markus,
> 
> I'm sorry, but that is still no excuse.  The global /etc/ld.so.preload
> should never, ever be used as the standard way of installing anything.
> Imagine if multiple drivers decided that was the right way to operate?
> Which would come first, how would you debug their interactions, and how
> would we ever keep a Linux system stable?
> 

the layer in-between is very thin, to the system calls. The main issue was a 
colliding symbol. We renamed it on our side and it is fixed now.

This mechanism has been tested for 2 years by many users so far.
By time doing all that people reported many bugs to us, even unrelated ones 
which belong to other projects. (eg. tridgell wrote that we cause issues with 
KDE because he found one post, he did not even read the post because it was a 
duplicate xine bug).
It's very unlikely that we cause any issue here. And the users still have the 
possibility to remove the driver, or just to use LD_PRELOAD.

> > If issues come up and are reported to us we take 
> > care about them.
> 
> I really think this is the wrong way around.  You are essentially doing
> a binary insertion of your code into every single process on the system,
> and just hoping that you emulate the applications expected behaviour of
> 42 different symbols.  This includes overriding functions that are
> internal to the application - they could do anything, so there is no way
> to know what is 'right'. 
> 
> > The reason for all that is that the preloading mechanism provides very high 
> > backward compatibility (one compiled driver works with Linux 2.6.18+), it 
avoids 
> > the need of having to compile drivers. And since updating the drivers also 
works 
> > very quick customers can easily handle this.
> 
> That it is easy does not make it right.  This is the wrong way to
> develop any kind of Linux driver, no matter how specialised or now 
> 
> If you want to make this easy for your users, then do it properly, and
> get the distributors to include it in the default driver set.  That way,
> anyone can use it, right out of the box.
> 
> > Last but not least we'll take over fixing this of course.
> 
> So you will stop using ld.so.preload?  I'm sorry, but that is the only
> real fix to this problem. 
> 
> > Andrew, sorry for wasting your time with this.
> 
> What we need, as I understand tridge has already said, is for you to
> ensure that your code is never again inserted into an unrelated process.
> How you do that is up up to you, but while this mechanism is used, this
> will break again.  
> 
> I'm sorry to have to be so harsh about this, on top of tridge's blog
> post http://blog.tridgell.net/?p=141 but pulling tricks like this
> pollutes the Linux landscape for everyone else.  
> 

ya sorry to say but this blog entry is dumb, and shows that the author has no 
experience with particular systems and neither understood what I wrote to him.

We provide Linux support with one single binary per architecture.
The optimal case would be that LD_PRELOAD or ld.so.preload is not used of course
but the linux multimedia stack currently depends on kernelspace drivers.

Our driver runs completely in userspace, when we release new devices
we can cover all systems down to 2.6.18 (and the only reason for 2.6.18 is 
because
kernelbuffers are too small for our USB devices, increasing those will provide 
support
until <(something less)2.6.10

There are also some nifty mechanisms in it for analog TV and audio handling, 
something
a kernel driver could never handle by itself - but essential for an enduser to 
say "yes this works", aside of that it supports a network mode
to provide the functionality of one device on another host.
And everything is within one driver package - one single binary.
The project is far more complex than this single library.

> I understand it if you think that if someone has your TV stick
> installed, that they must be a media PC, and so you can 'safely' pull
> tricks like this, but as our reporter has shown, you can never know what
> software will be co-installed.  The only way to make this whole system
> work is for us all to live by the rules.
> 

We keep searching with google for issues or people report issues directly to us,
it has shown that it works out very well.
Using ld.so.preload is very difficult, to get it right with all systems, it 
requires alot
details to be covered by itself - but we finally managed to have it work very 
well.

There are no "rules", things have to work and that is the only rule.
If you look around you cannot compile any new driver with old kernels, while our
mechanism works out of the

Best Regards,
Markus Rechberger