
On Po 15-03-21 15:39:48, Michael Matz wrote:
On Fri, 12 Mar 2021, Libor Pechacek wrote: [..]
Encouraged by the success, I've entertained the idea of getting rid of the LD_PRELOAD. So, I tried:
$ gcc -Wl,-rpath,\$ORIGIN -Wl,-rpath,/data/src/libpulp/lib/.libs -L. \ -L ../lib/.libs/ -o main main.c -lworkload -lpulp
And, voilà! I can just run "main" and live patch it without any extra hassle.
Of course, that's nothing to do with $ORIGIN, though. You linked against libpulp, hence it's loaded, hence it can be used by the ulp tool to live patch the process.
Yes. I realize that my message was too brief and there were too few words between neighboring ideas. :) My intent is exactly what you describe. The only information bit I withdrew is that when I link libworkload.so with libpulp.so (gcc -shared ... workload.c -lpulp), then the 'main' process aborts with weird messages right after start on my system.
The problem is the following: imagine you have a live patchable libfoo, and a random collection of binaries linking against libfoo. (To see the size of that random set, imagine libfoo being libc.so.6). Do you want to make all these binaries live patchable (or to be precise: processes resulting from execve(2) of these binaries) simply by installing the live patchable libfoo? Even if enabling live patching for a process induces a performance hit? Even if you decide to say "yes" to this question: do you want to have to link all these binaries against libpulp (which comes with the problem that suddenly those binaries only work when libpulp is installed, even though they themself don't make use of any live-patching facilities).
Agreed. This is the distro vendor view. I imagined an ISV who want to live patch their own shared library in their own set of applications. For such a user, shotgun approach might be valid.
You could also link a live patchable library against libpulp (and so make any process using that library also be live patchable). But that has some interesting consequences about entry tracking: it starts globally for a process only when libpulp is loaded, so anything loaded before libpulp is loaded isn't tracked. This might not be a problem, as normally it should be only required to track stuff in the live-patchable libs, but we punted on that.
Good point. Thanks for the remark!
So, for now we decided to let the answer to the question "should a process be live patchable?" be a policy decision that is expressed through environment variables.
Makes sense. As I wrote in my other message, I'm exploring the possibilities and evaluating the options. This one was moticated by the hypothetical situation in which LD_PRELOAD cannot be propagated though some proprietary and/or complicated start-up code. Thanks for your insights.
I don't know of a good solution to some of the above sub questions :-/
(Hint: you can force preloading a library to all processes ever started by using /etc/ld.so.preload)
Aieee. ;-) Libor -- Libor Pechacek SUSE Labs Remember to have fun...