- Jan 05, 2021
-
-
Simon McVittie authored
We previously parsed this to decide whether we could use --unshare-uts, but we stopped doing that more than a year ago, in commit 210fbd8c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes it a bit easier to reason about what we do and don't need. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 17, 2020
-
-
Simon McVittie authored
To work around older versions of GLib having a potential deadlock in their fd-closing code due to use of non-async-signal-safe functions in the forked child process, the Flatpak-derived code we're using here uses a simple, naive implementation of closing fds: it iterates through every possible fd, up to the rlimit. Unfortunately, Wine users sometimes set their fd rlimit very high (typically around a million), because the "esync" mechanism in Proton's Wine needs a lot of fds. The time taken by each individual syscall is not significant, but when we do a million of them, it adds up. This is arguably a misconfiguration - the recommendation is now to have a soft rlimit of 1024 and a hard rlimit of about a million, so that only processes that opt-in to dealing with a million fds have to be aware of them - but a significant number of misconfigured systems probably still exist. We don't actually *need* to close all the fds here: there's no security boundary, so giving the child access to unnecessary fds isn't a privilage gain; the parent process outlives the child, so leaking fds won't result in them never being closed; and in any case we're reasonably careful to set CLOEXEC on all our fds. So let's just not close them. In particular, this can save literally a million syscalls per helper subprocess invocation (it's not often I get to say that!), reducing pressure-vessel-wrap launch time by 90% on a system with the high fd limit (about 70 seconds down to 7). With the recommended soft limit of 1024, the speedup is less dramatic, but it still takes off nearly 10% (about 6 down to 5.5). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 15, 2020
-
-
Ludovico de Nittis authored
Previously we used the empty directory as an indicator that the capture of the library failed, but this worked only if we always started with an empty directory. And this is not the case when we are not using a subdir. For this reason, even if the capture of a library failed, we didn't set its "kinds" to "NONEXISTENT", and this could have leaded to errors like having duplicated Vulkan implicit layer JSON for the same name and different "library_path", one pointing to the correct ABI and the other to the wrong one. Fixes: #45 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Dec 14, 2020
-
-
Simon McVittie authored
This means we use all the search paths that steam-runtime-tools knows about, and in particular we respect LIBGL_DRIVERS_PATH and a Slackware-specific path. It also means we stop collecting "extra" drivers, which is potentially dangerous, as justified in the previous commit. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/318 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 11, 2020
-
-
Simon McVittie authored
We can make life easier for the VA-API and VDPAU driver loaders by trying to put everything in one directory, as we already do for DRI. We might as well do the same for Vulkan and EGL, where the names we choose are completely arbitrary anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of building a list of drivers and then converting it into a search path, we can build the search path as we go. The only side-effect is that previously we interleaved x86_64 and i386 paths, but now we put all the x86_64 paths before all the i386 paths. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Because capsule-capture-libs doesn't overwrite existing symbolic links, in the unlikely event that s2tc exists in more than one directory in the search path, we want to look at the highest-precedence first. The reversed order was correct for the current implementation of collecting DRI drivers, but not for s2tc. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This hasn't been true since af22427b. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If /tmp is a symlink in the current execution environment, then when we ask bwrap to bind-mount /tmp/pressure-vessel-wrap.XXXXXX/overrides over itself, it will try to create the parent directory /tmp, and fail because there's a symlink in the way. Canonicalize the path and use that instead. Partially addresses https://github.com/ValveSoftware/steam-runtime/issues/321 (symlinks "above" the home directory have the same problem, but are harder to fix). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 10, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This brings it in line with the other code path here, which tolerates containers that are single-architecture. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The Vulkan and EGL JSON manifests are more similar than they are different, so let's handle them through the same code (which I already factored out into smaller functions). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of having a function to make a list of Vulkan layers and/or ICDs available, let's have a function to act on a single layer or ICD. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
srt_vulkan_layer_get_json_path() and srt_vulkan_icd_get_json_path() return paths relative to the SrtSystemInfo's sysroot (the graphics driver provider), which might be the root filesystem, but might equally be /run/host when we're running inside Flatpak. Rename this variable accordingly. We were already using it correctly: the third argument to pv_runtime_take_from_provider() is a path in the provider sysroot. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Paths derived from self->overrides are valid in the current execution environment, but if we're running in a Flatpak environment, that's not the host. Rename them accordingly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We are not going to be able to do this from within Flatpak, and it is unsuitable for running runtimes other than Steam Runtime 1 'scout', for which the LD_LIBRARY_PATH runtime mostly already works. If we need an automatic fallback to running on the host for scout games, we can do that better by running `pressure-vessel-wrap --test`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, pid-based IPC between the Steam client and the game will fail. This is not expected to work if bwrap on the host is setuid, so it will not work for users of Debian, Arch linux-hardened, etc., but it's better than nothing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Because we were testing for a prefix match with a trailing slash, when FlatpakExports exports /home/me, we would not rewrite it to /home/me/.var/app/com.valvesoftware.Steam. Instead of adding the necessary special cases, use a slightly refactored version of flatpak_has_path_prefix(), which already does what we need. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of asking flatpak-spawn to use Flatpak's D-Bus API, we can use pv-launch to talk to the same D-Bus API, which gives us one fewer component to align to get a working prototype. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we're doing the equivalent of `flatpak-spawn` or `flatpak-spawn --host`, we can emulate the unset-env option by running `env -u`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We only need this in one branch. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 09, 2020
-
-
Simon McVittie authored
Since !173, we have been able to create symbolic links to graphics drivers anywhere on the filesystem, but that didn't mean the graphics driver would necessarily be usable, because the directory containing it would not necessarily be visible in the container. Add these directories to the list of directories to be "exported". Manual test (Debian on on Intel hardware, adjust as required for others): * Modify /usr/share/vulkan/icd.d/intel_icd.i686.json to use /opt/moved-from-usr/lib/i386-linux-gnu/libvulkan_intel.so * Move the real i386 libvulkan_intel.so to that location * ./run --verbose -- steam-runtime-system-info 2>&1 | tee container.log Resolves: #29 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/313 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 08, 2020
-
-
Simon McVittie authored
This module interposes in front of g_object_get(), and is known to cause crashes, even in programs that use GObject but not GTK, such as either pressure-vessel-launch or pressure-vessel-launcher (it's unclear which). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/286 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 04, 2020
-
-
Simon McVittie authored
Some OS distributions, notably Exherbo, don't put /usr/bin in their PATH. This means we can't safely use their PATH to invoke standard tools inside the container. Bypass this by setting the PATH without using env(1). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise we can't produce full system diagnostics from the included copy of steam-runtime-system-info. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
https://repo.steampowered.com/steamrt/ sometimes lags behind the image releases, due to its relationship with the LD_LIBRARY_PATH runtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we wrap steam-runtime-system-info in a shell script, its argv[0] will be ld.so, which makes it fail to find its own relocatable prefix in _srt_find_myself(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that s-r-t contains LGPL and Apache-2.0-licensed code, we should reflect that here. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 03, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In particular, when using a SDK runtime, we need to delete overridden 32-bit libraries from /lib32 as well as /lib/i386-linux-gnu. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We return the library directories in most-important-first order here, because that seems like the one that makes most sense (and matches LD_LIBRARY_PATH). When we go looking for DRI drivers, we actually want to take the least important first, but iteration over a GPtrArray in reverse order is easy. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-