- Aug 05, 2024
-
-
Simon McVittie authored
This will allow the output of capsule-capture-libs (and in principle other tools) to be piped to a log handler such as `logger --prio-prefix`, `systemd-cat --level-prefix=true` or `srt-logger --parse-level-prefix` which will filter or format the messages according to their severity. As currently implemented, fatal errors are emitted as LOG_ERR, warnings are LOG_WARNING, and all debug messages are LOG_DEBUG. A facility such as LOG_USER is not included: this is optional for logger(1), and not allowed for systemd-cat(1) and srt-logger. steamrt/tasks#444 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a couple of places this requires explicitly emitting the stringified value of errno, because we have equivalents of warnx() and errx(), but not warn() and err(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 05, 2024
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The ld_libs data structure is pre-allocated at maximum size instead of using dynamic memory allocation, in an effort to avoid use of malloc() during critical-path interactions with basic shared library infrastructure. This makes it about 1 MiB, so if users have reduced RLIMIT_STACK from its post-1995 default of 8 MiB for whatever reason, it doesn't take many levels of recursion to exceed that limit. The symptom for a stack overflow is particularly un-diagnosable (instead of exiting unsuccessfully with an error message, the program will just segfault), so allocate this data structure on the heap instead, which gives us the opportunity to log "libcapsule: out of memory". The equivalent data structures within libcapsule itself are still allocated on the stack, to avoid introducing new memory allocation inside a critical section. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/653 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 26, 2023
-
-
Simon McVittie authored
libcrypt.so.1 is build-time optional since glibc 2.28, and is not built by default since 2.38. In newer distributions like Debian >= 11 and Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian, and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2 and optionally a secondary build as libcrypt.so.1 (as in Arch). Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI, adding some functions and symvers of its own, it is backward- but not forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a replacement for glibc libcrypt.so.1, but it is not OK to do the opposite. This means it would be incorrect for us to use a system copy of glibc libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a container's libxcrypt libcrypt.so.1, even if the system copy of glibc is strictly newer than the container's glibc (for example, Steam Runtime 3 'sniper' is based on Debian 11, so it comes with glibc 2.31 and libxcrypt). Unlike libpthread, libdl and librt, symbols from `libcrypt.so.1` were never absorbed into `libc.so.6`, so we don't have to apply the reasoning seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+". In practice we've always got away with it in the past, but it's something that could cause a crash or incompatibility. I'm now looking into the possibility of backporting libxcrypt into Steam Runtime 1 and 2 (steamrt/tasks#332), which makes it more important to get this right. Accordingly, exclude libcrypt.so.1 from that special treatment, and instead set it up to be compared separately using the same comparators we use for glibc: by public symvers, then by public symbols, and as a last resort by name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Just for completeness, we're not going to support any of these any time soon. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 02, 2023
-
-
Simon McVittie authored
`warn(fmt, args)` is equivalent to (pseudocode) `warnx(fmt + ": %s", args, strerror(errno))`. In contexts where we do not have a useful value for errno, or where we are showing an error message that should already contain a previous result of strerror, we should use warnx() instead. This avoids showing a misleading errno which might have been set for some unrelated reason. Prompted by jupiter/tasks#887. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 01, 2023
-
-
Simon McVittie authored
If one of these happens, then something odd is going on and we should diagnose it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids having to turn on noisier options that CAPSULE_DEBUG=tool to see this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 06, 2022
-
-
Ludovico de Nittis authored
Add a stricter version of `soname:`, where a library is considered to be a match only if its DT_SONAME is exactly what capture-libs was asked to look into. This can be used as a protection against misconfigured systems where two incompatible libraries have been symlinked. E.g. if there is an unexpected symlink `libudev.so.0 -> libudev.so.1`, with `soname:libudev.so.0` we will import `libudev.so.0` inside the container even if its DT_SONAME is `libudev.so.1`. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 25, 2021
-
-
Ludovico de Nittis authored
The flag `CAPTURE_FLAG_EVEN_IF_OLDER` is not supposed to be considered pertinent if we are checking a library dependency. For this reason when we evaluate if a library dependency is a glibc sub-lib, we should skip checking if `CAPTURE_FLAG_EVEN_IF_OLDER` is set. This fixes an issue when capturing libraries with the pattern `gl:`, while using an host system with glibc <= 2.33 and a container with glibc >= 2.34. In this situation we were wrongly choosing `libpthread.so.0` from the provider and `libc.so.6` from the container. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com> Co-authored-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 06, 2021
-
-
Starting from glibc 2.34, libc.so.6 is a regular file instead of a symlink. Also all the symbols from its small libraries like libpthread, librt etc., are now moved into libc.so.6. This leads to two issues: 1. The default comparison by name doesn't work anymore for libc.so.6 2. Counting symbols or symbol-versions for the small libraries of glibc is not going to work. For this reason, if we are capturing a small library of glibc, we first try libc.so.6, using an hard-coded comparison by versions, symbols and name. After that we will take the requested library from the same place where we also took libc.so.6. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 02, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 18, 2021
-
-
Simon McVittie authored
To select SONAMES that match a glob pattern, we want to use the soname-match mode, not the soname mode. Spotted by @luigipiucco on <https://github.com/NixOS/nixpkgs/issues/100655 >. Thanks: Luigi Sartor Piucco Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 25, 2020
-
-
Simon McVittie authored
I'm using Exherbo as an example of a host OS with an unusual layout that breaks libcapsule's assumptions. Tested in an x86_64 Docker container, but i386 is symmetrical and should also work. This also puts the framework in place to deal with other distributions' architecture-specific ld.so caches. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 20, 2020
-
-
Ludovico de Nittis authored
If you don't want to change the link target for all the symlinks that will be created, instead of using `--link-target`, it is now possible to use the new `--remap-link-prefix` and just list the directories that should be located under a different target. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 21, 2020
-
-
Ludovico de Nittis authored
If we have the CAPTURE_FLAG_IF_EXISTS option flag, we should not propagate an error if we are not able to find some dependencies of a library. Instead we should just skip it. This fixes an error that some users reported because they had some leftovers unused libraries in their system and libcapsule reported an error while trying to capture their (missing) dependencies. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Aug 27, 2020
-
-
Ludovico de Nittis authored
We are now able to list the symbol versions and/or symbols that are known to be public/private. This is especially useful for comparing libraries that removed symbol versions, or symbols, from one release to another. As this already happened multiple times in the past, like for example with `libdrm_nouveau.so.2` or `libedit.so.2`. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 07, 2020
-
-
Simon McVittie authored
This gives capsule-capture-libs a source of library-specific knowledge. For example, if we know that: * libgcc_s.so.1 is installed with an unhelpful name, but it uses versioned symbols the way you'd hope; * libdbus-1.so.3 is installed with a helpful libtool-style name, but has private symbols that defeat our current simplistic comparisons then we can express that as: [Library libgcc_s.so.1] CompareBy=versions;symbols; [Library libdbus-1.so.3] CompareBy=name; A runtime that contains a known set of libraries would be a good place to put library-specific knowledge about those libraries. For example, the maintainers of the Steam Runtime know what libraries it contains, and are well-placed to compare those libraries with their counterparts in mainstream distributions. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is primarily useful for testing and experimenting. Using versions by default in preference to filenames (--compare-by="versions,name") looks like it might be viable, but is a destabilising change that we should test more before considering a change of defaults. Meanwhile, counting symbols as a fallback (--compare-by="...,symbols") does not look as safe as we had hoped, because if a library maintainer has cleaned up their ABI by hiding private symbols without adding any new symbols, we will sort libraries in exactly the wrong order - and in reality, that seems to be what has happened in several libraries, for example libX11.so.6 and libXfixes.so.3. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can pass other state through this, such as the comparators to be used to compare libraries. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us unit-test it more easily. While I'm moving it, re-indent it in libcapsule's coding style (4 rather than 2 space indents). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 03, 2020
-
-
Simon McVittie authored
The pressure-vessel tool used in the Steam Runtime has an increasingly long list of graphics libraries which might be better as a file than on the command-line. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 14, 2019
-
-
Simon McVittie authored
This crashes when tests/capture-libs.pl loads libgobject-2.0.so.0 on Debian 10 'buster' or on Debian unstable: Stack trace of thread 87172: #0 0x00007f6cad431176 g_slice_free1 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2) #1 0x00007f6cad431bc0 g_slist_remove (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2) #2 0x00007f6cad43bf47 g_once_init_leave (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2) #3 0x00007f6cad4f8e24 n/a (/tmp/fpzde0iMLo/host/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6200.2) I suspect this might be because the version of GLib in /usr and the version in /tmp/.../host/usr both get loaded into the same address space? This reverts commit fff84ffb. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 11, 2019
-
-
Simon McVittie authored
I don't know the right predefined macros to detect these, so they're just comments for possible future reference. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We have no plans to support big-endian 64-bit ARM, but since we have a reasonably comprehensive list here, we might as well include it. Reference: <https://wiki.debian.org/Multiarch/Tuples>, <https://sourceware.org/glibc/wiki/ABIList#aarch64 > Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This was probably copy/paste damage from some other architecture. According to https://sourceware.org/glibc/wiki/ABIList these architectures are 32-bit (or technically 31-bit for s390) and install their ld.so in /lib. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
When two libraries have the same numeric tail we were not able to reliably determine which one was the newer. Now we also check the libraries definitions and the symbols to make a more weighted decision. The order of comparison is currently: compare version definitions > compare numeric tail > one has strictly more symbols If even after these three checks we are still not sure which one to choose, we pick the provider as the default.
-
- Sep 26, 2019
-
-
Simon McVittie authored
On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most shared libraries. However, on Fedora 30 it is a symlink to a versioned name like libgcc_s-9-20190827.so.1. The name used in Fedora happens to be less than libgcc_s.so.1 in strverscmp() order, causing capsule-capture-libs to prefer the Debian/Manjaro libgcc_s.so.1, even if the container is older. This can cause problems if an old Debian-derived container like the Steam Runtime is used on a newer Fedora host, with host graphics drivers imported by using capsule-capture-libs: the container's libgcc_s.so.1 does not satisfy the versioned symbol requirements of the graphics driver, causing loading to fail. Treat a regular file libgcc_s.so.1 as indeterminate order (or "equal"), so that we fall back to the default behaviour, which is currently to take the host version of the library in the case of a tie. This is a stopgap solution: ideally we would consider the versioned symbols exported by both libraries, and take whichever one has a superset of the version definitions exported by the other, if there is a strict superset in either direction (in the case of libgcc, in fact there is). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This reverts commit faf3daa9, which was merged with an outdated commit message. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 19, 2019
-
-
Simon McVittie authored
On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most shared libraries. However, on Fedora 30 it is a symlink to a versioned name like libgcc_s-9-20190827.so.1. This can cause problems if a Debian-derived container is used on a Fedora host, with host graphics drivers. TODO: it isn't clear whether this change makes any practical difference, because strverscmp("libgcc_s.so.1", "libgcc_s-9-20190827.so.1") == 0 anyway.
-
- Sep 18, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 25, 2019
-
-
Simon McVittie authored
They now all take named options (including the -- pseudo-option) for future expansion, and fail with an error if given too many positional parameters. When libcapsule tools are bundled with a larger project, this should make it easier to check which ones they are. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 24, 2019
-
-
Simon McVittie authored
On Red Hat-derived OSs, /usr/lib/dri contains 32-bit drivers (with their 64-bit equivalents in /usr/lib64/dri), but on Arch Linux-derived OSs it contains 64-bit drivers (with their 32-bit equivalents in /usr/lib32/dri). As a result, we have to run both i386-linux-gnu-capsule-capture-libs and x86_64-linux-gnu-capsule-capture-libs against if-exists:path-match:/usr/lib/dri/*.so, ignoring anything we find that is of the other word-size. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 16, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 30, 2019
-
-
Simon McVittie authored
In Ubuntu 12.04, this is declared in a header that we include. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-