From: Kozlukov Sergei <sergei.kozlukov@aalto.fi>
To: "libc-help@sourceware.org" <libc-help@sourceware.org>
Subject: A public interface for library search
Date: Tue, 14 Nov 2023 00:11:14 +0000 [thread overview]
Message-ID: <AS8P192MB119183FE036AE0E97C24DCDB98B3A@AS8P192MB1191.EURP192.PROD.OUTLOOK.COM> (raw)
Hi! I wasn't sure if this was worth a ticket on BugZilla yet, I hope libc-help will be an appropriate venue.
I'm trying to assess if there's such a thing as an agreeable interface for locating the host platform's shared libraries. Specifically, if there's a "conventional" way of predicting, given a soname, what specific file the `dlopen()` would have loaded, but without actually loading it.
This task is, I think, precisely what certain container-related projects try to accomplish by peeking into the /etc/ld.so.cache, with the purpose of locating the userspace drivers that need to be mounted into the container (think mesa or, most realistically, libcuda.so):
- https://github.com/NVIDIA/libnvidia-container/blob/1eb5a30a6ad0415550a9df632ac8832bf7e2bbba/src/nvc_ldcache.c#L370
- https://github.com/NVIDIA/nvidia-container-toolkit/blob/da0755769fee3ab071aaa3b9fac6fe085da7071d/internal/ldcache/ldcache.go#L36
These tools are then used by many downstream projects, e.g. apptainer/sylabs-singularity, docker, etc.
As far as I can tell, /etc/ld.so.cache is glibc internals and isn't meant to be used as a public interface. In particular, NixOS does not populate that file, and the nixpkgs simply patch all software that refers to it.
I think this behaviour has to change upstream, in those projects, and for that we need an interface that could be considered "conventional", "maintstream", and "supported".
The combination of `dlopen` and `RTLD_DI_ORIGIN` are almost perfect for the task: they respect LD_LIBRARY_PATH, LD_PRELOAD, and even the inquiring process's RUNPATH. Unfortunately, that comes with the side-effect of executing the loaded libraries' constructors. I understand that this shouldn't be a security concern, at least in the specific case of nvidia's container-toolkit and from glibc's perspective. However, there's no good reason to actually "load" the libraries being searched for, so I expect that this solution would be, generally, hard to sell.
Thanks!
next reply other threads:[~2023-11-14 0:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 0:11 Kozlukov Sergei [this message]
2023-11-14 11:39 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AS8P192MB119183FE036AE0E97C24DCDB98B3A@AS8P192MB1191.EURP192.PROD.OUTLOOK.COM \
--to=sergei.kozlukov@aalto.fi \
--cc=libc-help@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).