Comment 18 for bug 1913421

On Thu, Feb 11, 2021 at 2:45 PM Dan Streetman
<email address hidden> wrote:
>
> Another completely different alternative approach might be for us to see
> if upstream qemu is willing to simply open all the module files when
> qemu starts, and leave the fd open until exit.

We've had that discussion the first time it came up, but that wasn't
an approach anyone likes.
It has too many bad attributes:
- keeping files open that are removed is considered not-good
- bloating the active binary is considered very bad and by mapping all
that would happen
- There are more awkward cases, like starting guests, then installing
qemu-block-extra later and then hot-plugging
   Valid but not working with this approach.

> That way even if the module files are removed, any still-running qemu
> process(es) would still have an open fd to them and (at least on UNIX
> systems) should be able to load them, since the kernel won't actually
> fully remove them until all open descriptors are closed.
>
> I haven't tested that and I'm not sure if there are possible issues with
> mmaping removed files, but in theory it should work.
>
> ** Merge proposal linked:
> https://code.launchpad.net/~ddstreet/ubuntu/+source/qemu/+git/qemu/+merge/397904
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1913421
>
> Title:
> Load of pre-upgrade qemu modules needs to avoid noexec
>
> Status in qemu package in Ubuntu:
> In Progress
> Status in qemu source package in Bionic:
> Confirmed
> Status in qemu source package in Focal:
> Confirmed
> Status in qemu source package in Groovy:
> Confirmed
>
> Bug description:
> This is a continuation of bug 1847361.
>
> Since that is in Ubuntu and Debian we are:
> - correctly saving the modules to those paths in /var/run/qemu.
> - qemu tries to load from that path as fallback
> - that works fine in containers running qemu/kvm
>
> But there is an issue on non-container systems as /run usually is like
> this:
>
> tmpfs on /run type tmpfs
> (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755)
>
> The important bit here is the "noexec" which is intentional (for
> security reasons), but prevents the loading of shared objects from
> that path.
>
> The path is good for many reasons (it is auto-cleaned, upstream and
> Distros agreed to this one path, ...). Moving it to other places also
> quite likely might have unpredictable options.
>
> In a discussion between Victor (thanks for all the pushign and inpot
> on this) and Marc (security POV) we have come to a solution that will
> make just the subpath that is owned by qemu to not have noexec set.
>
> This bug shall track preparing this fix for Debian / Ubuntu and the
> latter SRu considerations on the same.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1913421/+subscriptions

--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd