Skip to content
Snippets Groups Projects
  1. Jan 31, 2025
    • Simon McVittie's avatar
      pv-wrap: Use a more realistic multiarch tuple for unit tests · d33604f3
      Simon McVittie authored
      
      All of our supported architectures define _SRT_MULTIARCH from the build
      system, and pressure-vessel can't be compiled for other architectures
      without defining _SRT_MULTIARCH, so we don't need to override this
      to a mock string; we can leave it set to the real multiarch tuple of the
      architecture.
      
      This avoids setting up inconsistencies between this code path, and other
      parts of pressure-vessel that do not force a mock architecture.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d33604f3
    • Simon McVittie's avatar
      pv-wrap: Have test coverage for the single-architecture case · de82a412
      Simon McVittie authored
      
      Until now, the case where only one architecture is supported has only
      been tested if pressure-vessel was built for a non-x86 architecture
      such as ARM, which is rarely (if ever) done.
      
      We can get coverage for this case by making pv-wrap behave as if only
      the first architecture was supported, as a runtime rather than
      compile-time decision: this means that an ordinary x86_64 build can
      exercise both the x86 and non-x86 code paths.
      
      This is important because steamrt/tasks#595 will add new code that
      differs according to whether there is only a single architecture,
      or more than one.
      
      In the test, this means we need to be able to mark which of the expected
      paths are expected on i386 only, and which ones are expected in general.
      Instead of the verbosity that would result from turning all of our
      test data into structs, I've done this with an ad-hoc mini-language:
      the ones that are only expected on i386 are prefixed with `i386:`.
      
      We also might conceivably want to make use of something similar to
      PV_APPEND_PRELOAD_FLAGS_ONE_ARCHITECTURE in production in future, if
      we start providing legacy-free containers that only support running
      x86_64 games.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      de82a412
    • Simon McVittie's avatar
      pv-wrap: Document PV_APPEND_PRELOAD_FLAGS_IN_UNIT_TESTS · be7d6382
      Simon McVittie authored
      
      Fixes: 08751fff "tests: Assert that modules with ${LIB} or ${PLATFORM} are handled"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      be7d6382
    • Simon McVittie's avatar
      pressure-vessel: Avoid looping through zero-length array of emulator hosts · 4524f7a6
      Simon McVittie authored
      
      If compiled for a non-x86 architecture, we don't expect to be emulated
      by some foreign architecture with a mechanism like FEX or qemu-user,
      so PV_N_SUPPORTED_ARCHITECTURES_AS_EMULATOR_HOST is zero.
      In this case don't try to allocate and loop over an array of length 0.
      This also avoids gcc warnings with -Wtype-limits,
      "comparison of unsigned expression in ‘< 0’ is always false".
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      4524f7a6
    • Simon McVittie's avatar
      pv-wrap: Remove redundant reinitialization of SrtSystemInfo · 0f9b4eef
      Simon McVittie authored
      
      Instantiating this can't fail, and if it somehow does, trying it again
      is unlikely to help.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      0f9b4eef
  2. Nov 28, 2024
  3. Nov 21, 2024
  4. Nov 18, 2024
    • Simon McVittie's avatar
      pressure-vessel: Generate /etc/passwd, /etc/group for the container · 23a52654
      Simon McVittie authored
      Sometimes our current uid will not be present in /etc/passwd.
      For example, when using systemd-homed the equivalent of a passwd(5)
      record is synthesized by libnss_systemd. A similar thing could happen
      when using a remote user directory like LDAP, or for the group database.
      
      Inside the container, we have the basic nsswitch plugins from glibc
      (notably libnss_files, which reads /etc/passwd and /etc/group), but
      we do not have access to non-standard nsswitch plugins like
      libnss_systemd or LDAP. This can cause crashes or bugs in games that
      assume that `getpwuid(getuid())` will always succeed (like Factorio),
      especially if they do not respect `$HOME` (like Factorio).
      
      Instead of bind-mounting the host system's /etc/passwd and /etc/group
      as-is, we can synthesize a /etc/passwd and /etc/group that are
      guaranteed to contain at least our uid and primary gid, matching what
      Flatpak does.
      
      Flatpak generates very minimal files that list our uid and gid, plus
      the default overflow uid and gid 65534 (labelled as `nfsnobody` for
      historical reasons). However, pressure-vessel has historically provided
      more complete files, so it's conceivable that a game might be relying
      on being able to resolve (for example) root as uid 0; so we copy
      everything from the host /etc/passwd and /etc/group, excluding only
      the line(s) that would duplicate the one we synthesize.
      
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/705
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23a52654
  5. Nov 05, 2024
    • Simon McVittie's avatar
      pv-adverb: Set SDL_DYNAMIC_API to a suitable value on request · 0f1133b3
      Simon McVittie authored
      
      It's difficult for users of non-Debian-derived distros to select the
      runtime's SDL, especially if they don't know whether the game is 32- or
      64-bit, because the expansion of `$LIB` and `$PLATFORM` varies between
      distro glibc builds.
      
      However, we can normally predict `$LIB` and `$PLATFORM` well enough to
      do the right thing programmatically. For example, if `$PLATFORM` expands
      to `i686` in 32-bit processes and `xeon-phi` in 64-bit, then we can
      create symlinks at `/tmp/XX/i686/libSDL2-2.0.so.0` and
      `/tmp/XX/xeon-phi/libSDL2-2.0.so.0`, and then set
      `SDL_DYNAMIC_API='/tmp/XX/${PLATFORM}/libSDL2-2.0.so.0'` to have the
      runtime linker dynamically select the correct word size.
      
      While I'm here, we might as well provide the same setup for SDL3.
      
      steamrt/tasks#578
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      0f1133b3
  6. Oct 30, 2024
  7. Oct 15, 2024
    • Simon McVittie's avatar
      pv-runtime: Use host versions of the libdrm family, if newer · 9d346343
      Simon McVittie authored
      In current Mesa versions, typically these are pulled in via explicit
      linking that generates a `DT_NEEDED` ELF header, either in individual
      DRI drivers in very old Mesa, in the Gallium "megadriver" in
      intermediate Mesa versions like the one in Debian 12, or in
      `libgallium-${VERSION}.so` in newer Mesa.
      
      However, Mesa merge request
      https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658
      
      
      suggests demoting the dependency on `libdrm_amdgpu.so.1` from
      `DT_NEEDED` to `dlopen()`. Changing that dependency from declarative to
      imperative breaks our ability to follow it, resulting in the container's
      older `libdrm_amdgpu.so.1` being used.
      
      In principle there's nothing to stop the same thing from happening for
      any of the libraries in the libdrm family, so look for all of them.
      For future-proofing, I've included all available drivers even if they
      are not available on x86 (but excluding exynos and omap, which seem to
      be only for 32-bit ARM hardware, which is probably no longer
      interesting).
      
      Tested-by: Dmitry Osipenko
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9d346343
  8. Sep 20, 2024
  9. Sep 12, 2024
    • Simon McVittie's avatar
      pv-runtime: If using host libxkbcommon, try to use host libxkbcommon-x11 · 652b6011
      Simon McVittie authored
      
      libxkbcommon is not really a graphics driver dependency as such, but
      it can end up being pulled in by graphics stack components, for example
      MangoHUD 0.7.2.
      
      libxkbcommon-x11 looks into private data structures from libxkbcommon,
      which is a reasonable thing to do since they come from the same source
      code and are upgraded at the same time, but can cause crashes if we
      pick up one but not the other from the graphics stack provider; so if
      we pick up libxkbcommon as a dependency of MangoHUD, we also need to
      take the matching libxkbcommon-x11 if it exists.
      
      If the graphics stack provider has libxkbcommon but not libxkbcommon-x11,
      there's really nothing we can do about that, so we will have to combine
      this change with trying harder to get Steam client packaging to pull in
      libxkb-common-x11.so.0.
      
      steamrt/tasks#530
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      652b6011
    • Simon McVittie's avatar
      pv-runtime: Generalize code to capture libraries related to glibc · 58c5d20c
      Simon McVittie authored
      
      Previously this was part of pv_runtime_collect_libc_family(), but in
      fact it's equally applicable for other libraries.
      
      For example, if we are using the host's libxkbcommon.so.0, we'll also
      want the host's libxkbcommon-x11.so.0 if at all possible, because
      libxkbcommon-x11 uses private data structures from libxkbcommon and
      will crash if they are not sufficiently similar.
      
      steamrt/tasks#530
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      58c5d20c
  10. Aug 22, 2024
  11. Aug 13, 2024
    • Simon McVittie's avatar
      Avoid deprecated g_qsort_with_data() · 45ed2aad
      Simon McVittie authored
      
      For historical reasons g_qsort_with_data() "only" works with up to 2**31
      items, so it won't necessarily work for pathologically large arrays
      and therefore is deprecated.
      
      The advantage of g_qsort_with_data() and its replacement g_sort_array()
      is that GLib guarantees that they are a stable sort (will not permute
      items that already compare equal), which is not a guarantee for glibc's
      qsort() and qsort_r(). However, in each of these places we are sorting
      the keys from a hash table, which are unique anyway, so there is no
      advantage to a stable sort.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      45ed2aad
  12. Aug 07, 2024
    • Simon McVittie's avatar
      pv-wrap: Don't make XDG_CONFIG_DIRS, XDG_DATA_DIRS available in container · 81de8678
      Simon McVittie authored
      
      Unlike XDG_CONFIG_HOME and XDG_DATA_HOME, these search paths are
      expected to be read-only, making it much less likely that a game or
      app component will misbehave if they contain a dangling symlink.
      
      Also unlike XDG_CONFIG_HOME and XDG_DATA_HOME, these paths are much
      more likely to contain OS-related path elements that can cause
      container runtime regressions, such as /var/cache (steamrt/tasks#434)
      and /var/lib (steamrt/tasks#493).
      
      A regression risk with this change is that if a user has set for example
      `XDG_DATA_DIRS=/offload/data:/usr/local/share:/usr/share`, since
      0.20240301.0 the result has been that /offload/data has been shared
      with the container, which means apps and games in a SLR container will
      load icons, .desktop files, etc. from that location. No longer doing
      this is both good and bad. It's good because it makes the container
      more self-contained again, but it's bad because users might have come
      to rely on `/offload/data` being available, which would no longer be
      the case after this change.
      
      steamrt/tasks#493
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      81de8678
    • Simon McVittie's avatar
      pv-utils: Reserve /var/run · f829ac7a
      Simon McVittie authored
      
      If the user has /var/run as a directory (not a symlink), and if they
      (unwisely) run with --filesystem=/var/run, then that would prevent us
      from creating the symlink `/var/run -> ../run`.
      
      steamrt/tasks#493
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      f829ac7a
    • Simon McVittie's avatar
      pv-utils: Treat /var/lib/dbus as a reserved path · e34ff8ef
      Simon McVittie authored
      
      We need to prevent /var/lib/dbus (and parent directories like /var/lib)
      from being shared with the container. Otherwise, a
      /var/lib/dbus/machine-id that is a regular file on the host can prevent
      us from creating it as a symlink (to /etc/machine-id) in the container.
      
      steamrt/tasks#493, steam-runtime#688
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      e34ff8ef
    • Simon McVittie's avatar
      3f81a707
  13. Aug 06, 2024
    • Simon McVittie's avatar
      pv-runtime: Silence spurious warnings for libnvidia-pkcs11 on Ubuntu 24.04 · 2822b8bb
      Simon McVittie authored
      
      My understanding is that these libraries are dlopen'd by other parts
      of the Nvidia driver for confidential-computing GPGPU use-cases, and
      unlikely to be critical for gaming.
      
      There are currently two implementations, one that depends on OpenSSL 1.1
      and one that depends on OpenSSL 3.0. The way they are packaged in Ubuntu
      means that in 24.04, the one for OpenSSL 1.1 is present but does not
      have its dependencies satisfied, leading to confusing warning messages
      from capsule-capture-libs that could confuse our users. Silence those
      messages by using the new "quiet:" pattern prefix.
      
      (The message is actually reduced to LOG_DEBUG level rather than being
      silenced, so CAPSULE_DEBUG=tool will reinstate it if someone needs to
      look at capsule-capture-libs behaviour in fine detail.)
      
      steamrt/tasks#488
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      2822b8bb
    • Simon McVittie's avatar
      pv-runtime: Run capsule-capture-libs with --level-prefix · 92df1959
      Simon McVittie authored
      
      This will let us highlight warnings and fatal errors from
      capsule-capture-libs as such.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      92df1959
  14. Aug 02, 2024
  15. Jul 31, 2024
  16. Jul 26, 2024
  17. Jul 19, 2024
    • Simon McVittie's avatar
      pv-runtime: Try to mount /usr/${LIB}/gconv into container · 744fecda
      Simon McVittie authored
      
      Previously we assumed that the hard-coded directory used to dlopen
      gconv modules matched the realpath() of the directory containing
      libc.so.6, disregarding any compatibility symlinks: for example, on
      Red Hat, 64-bit gconv modules are in /usr/lib64/gconv, and on Debian
      they're in /usr/lib/x86_64-linux-gnu/gconv.
      
      However, this turns out not to be true on Void Linux, where
      /usr/lib64 -> lib is a non-canonical path, but the hard-coded path
      that will be used to load iconv modules is /usr/lib64/gconv anyway.
      
      We cannot simply set GCONV_PATH, because apparently setting
      `GCONV_PATH=/usr/lib/gconv:/usr/lib32/gconv` will break 32-bit
      applications: unlike the equivalent with LD_LIBRARY_PATH, a 32-bit
      application would try and fail to load the 64-bit module from
      /usr/lib/gconv (it will fail to load because its word size does not
      match the word size of the process), and then will not fall back to
      /usr/lib32/gconv as one might expect.
      
      Luckily, on Void Linux, the libdl dynamic string token ${LIB} has been
      chosen such that the correct path for each architecture's gconv modules
      is /usr/${LIB}/gconv. We can use this as an additional guess at the
      necessary mount point for the gconv modules, mounting /usr/lib/gconv
      onto both /usr/lib/gconv and /usr/lib64/gconv - that way, it doesn't
      matter whether the path hard-coded in glibc matches our old heuristic
      or our new heuristic, because either one will work.
      
      steamrt/tasks#477, ValveSoftware/steam-runtime#680
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      744fecda
  18. Jul 18, 2024
  19. Jul 17, 2024
    • Simon McVittie's avatar
      pv-runtime: Don't try to mask /etc/vulkan/*.d · f926ea58
      Simon McVittie authored
      
      Since updating our Flatpak-derived code, every time we start a container
      we log messages like:
      
          N: Not replacing "/etc/vulkan/implicit_layer.d" with tmpfs: Path "/etc" is reserved by the container framework
      
      We only import selected directories from /etc into the container's /etc,
      and none of the directories below /etc/vulkan are among them, so there
      is actually no need to mask these directories. Silence the warning by
      not attempting to mask them.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      f926ea58
    • Simon McVittie's avatar
      Revert "pv-runtime: Add a mechanism to take custom CA certificates from the host" · 9e3d9c85
      Simon McVittie authored
      
      This was implemented in a way that assumed it would only be enabled
      on specially-flagged developer systems, making it acceptable for the
      implementation to be non-robust and make assumptions about the host
      systems on which it would be enabled; but current Steam betas enable
      it for the steamwebhelper unconditionally, which would cause serious
      regressions on non-Debian-derived, non-Arch-derived host OSs.
      
      Revert the addition of this feature to avoid regressions. Before
      reinstating it, we will either need to arrange for Steam to enable it
      conditionally as previously planned, or make the implementation fail
      gracefully and harmlessly on non-Debian-compatible host systems.
      
      This reverts commit d6a519f5.
      
      steamrt/tasks#416
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9e3d9c85
  20. Jul 09, 2024
  21. Jun 25, 2024
    • Simon McVittie's avatar
      pressure-vessel: Update Flatpak-derived code to Flatpak 1.15.8 · b7c4a69c
      Simon McVittie authored
      
      Many of the changes are `#if 0`. Main changes that have a practical
      effect on steam-runtime-tools:
      
      * Some former g_debug() has been promoted to g_info().
      
      * The majority of flatpak-run.c is now `#if 0`. The parts we use have
        mostly moved to `flatpak-run-*.c`.
      
      * Backports from newer GLib are now in their own translation unit.
        Some of them are `#if 0` because they are redundant with a copy
        in <steam-runtime-tools/glib-backports-internal.h>.
      
      * Flatpak now supports using the Wayland security context extension
        to mark Wayland connections as belonging to a specific
        (app ID, instance ID) pair; but this is not relevant for pressure-vessel,
        so we don't enable or use this feature.
      
      * Flatpak now supports using $WAYLAND_SOCKET to create Wayland
        connections with the security context extension, or optionally allows
        apps to inherit it directly; but this is not useful for
        pressure-vessel because it only accepts a single client connection,
        whereas a Steam game might consist of multiple Wayland clients, so we
        don't enable or use this feature.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b7c4a69c
Loading