public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
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!

             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).