Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Q qemu
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Jobs
  • Commits
Collapse sidebar
  • QEMU
  • qemu
  • Merge requests
  • !20

Fix saving modules on upgrades (LP: #1913421)

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Christian Ehrhardt requested to merge paelzer-guest/qemu:lp-1913421-noexec-mount-upgrade-modules-DEBIAN into debian-experimental Feb 16, 2021
  • Overview 24
  • Commits 4
  • Pipelines 11
  • Changes 2

Hi, the feature to save old qemu-block-extra modules is nice, but we've found a flaw in the path we selected.

The problem is that we use this for qemu .so files that are late-opened on hot-add. But the path that we chose (for reasons like auto-clean on reboot since it is tmpfs) is usually mounted as noexec which breaks the whole use case:

Ubuntu
ubuntu@h-pol:~$ mount | grep '/run '
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=48028k,mode=755,inode64)

Debian
root@debian:~# mount | grep '/run '
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=203932k,mode=755)

But not everywhere, e.g. Fedora33:

$ mount | grep '/run '
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=803912k,nr_inodes=819200,mode=755,inode64)

That is also the reason why - when we added this - all the testing worked fine as I was driving VMs inside of Ubuntu containers. And there we have:

root@h:~# mount | grep '/run '
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=6549840k,nr_inodes=819200,mode=755)

Due to that I didn't spot the problematic path mount option back then, but for a typical hosting use case you'd expect to have the Host on bare-metal and there this is a problem - therefore here proposal how to change things to make them work better.

And effectively this change becomes kind of a "Debianize module backup" just as we do similarly with some other paths that differ between distributions.

I still wait for some more input, in particular from our security people if they see any potential danger in the new path. But I wanted to open it up for you to also hear your opinion about this.

P.S. we went through several alternatives, details and so on - what I propose here seems to be the best tradeoff of all we've found so far. Suggested changelog entry:

* Fix saving modules on upgrades (LP: #1913421)
  - d/p/u/lp-1913421-keep-old-package-block-modules-in-usr-lib-dir.patch:
      change the fallback-load path from /var/run/qemu to
      /usr/lib/@{multiarch}/qemu/uninstalled/
    - d/rules: provide and install qemu-block-extra.tmpfiles to clear
      old modules on reboot
    - d/rules: change backup path to /usr/lib/@{multiarch}/qemu/uninstalled/
    - d/rules: clear directories on remove
    - d/rules: clear all modules on purge

On (any) path change we will also need to extend the libvirt apparmor rules what we allow. I will do that, but before doing so I'd want us to agree on a solution/path.

P.S. more discussions and former debate (not required, but if you want to dive deeper) in Ubuntu bug and Ubuntu MP

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: lp-1913421-noexec-mount-upgrade-modules-DEBIAN