Skip to content
Snippets Groups Projects
  1. Dec 17, 2020
    • Simon McVittie's avatar
      pressure-vessel: Let short-term subprocesses inherit non-CLOEXEC fds · 97b5a8f6
      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: default avatarSimon McVittie <smcv@collabora.com>
      97b5a8f6
  2. Nov 17, 2020
    • Simon McVittie's avatar
      bwrap: Don't bind-mount files into /etc as part of binding /usr · 23035e38
      Simon McVittie authored
      
      If we want to deal with strange operating systems that use a non-standard
      filename for ld.so.cache, we'll have to special-case it. There's
      little extra cost to doing this because we already need to understand
      how ld.so.cache works, to be able to generate our own with different
      search paths.
      
      In situations where we just want a quick container to be able to inspect
      the runtime, we can deal with this by mounting all of /etc read-only.
      
      For the final container, we already iterate over all the files in the
      runtime's /etc, which will "naturally" include ld.so.cache and
      alternatives.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23035e38
  3. Sep 29, 2020
  4. Sep 09, 2020
  5. Sep 02, 2020
  6. Sep 01, 2020
    • Simon McVittie's avatar
      wrap: Don't populate environment of FlatpakBwrap that will be merged · 07f02a83
      Simon McVittie authored
      
      The default for a FlatpakBwrap object is to copy the calling
      environment as a base for the environment that it will build up.
      However, that's wrong if we are going to merge more than one
      FlatpakBwrap together: the merged FlatpakBwrap's argv will be appended
      to the destination FlatpakBwrap, but the merged envp will overwrite the
      corresponding variables in the destination.
      
      Avoid this by making sure that every time we merge two FlatpakBwrap
      objects, one of them has an empty environment.
      
      Resolves: T23422
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      07f02a83
  7. Jul 29, 2020
  8. May 21, 2020
  9. Mar 04, 2020
  10. Feb 26, 2020
    • Simon McVittie's avatar
      bwrap: Don't create a /libexec symlink · 8ba50039
      Simon McVittie authored
      
      We want all the libQUAL directories, including lib32 and lib64 (and in
      principle also libx32, libn32 etc.), but we specifically don't care
      about libexec. Real systems don't usually symlink /usr/libexec into the
      root directory.
      
      If we create a /libexec symlink, the only effect it might have is that
      game developers start relying on it, which we certainly don't want.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      8ba50039
  11. Jan 06, 2020
    • Simon McVittie's avatar
      wrap: Tell child process to take out its own lock if necessary · d47b241c
      Simon McVittie authored
      
      Non-OFD locks don't propagate across fork(), and bwrap needs to clone()
      itself (which behaves like fork() in this respect) to separate itself
      into a parent outside the container and a child inside the container.
      
      This change adds a weak dependency on Linux 3.15. If we run on an older
      version, everything should still *work*, but there will be a short
      period of time during which we have already decided to use the runtime,
      but it is not locked (and in particular not protected from deletion).
      
      Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d47b241c
  12. Nov 12, 2019
  13. Sep 11, 2019
  14. Sep 10, 2019
  15. Sep 04, 2019
Loading