virtfs-proxy-helper for 9p filesystem shares deprecated in QEMU 8.1

[tomponline]

The 9p proxy filesystem backend driver has been deprecated and will be removed (along with its proxy helper daemon) in a future version of QEMU. Please use -fsdev local or -virtfs local for using the 9p local filesystem backend, or alternatively consider deploying virtiofsd instead.

The 9p proxy backend was originally developed as an alternative to the 9p local backend. The idea was to enhance security by dispatching actual low level filesystem operations from 9p server (QEMU process) over to a separate process (the virtfs-proxy-helper binary). However this alternative never gained momentum. The proxy backend is much slower than the local backend, hasn’t seen any development in years, and showed to be less secure, especially due to the fact that its helper daemon must be run as root, whereas with the local backend QEMU is typically run as unprivileged user and allows to tighten behaviour by mapping permissions et al by using its ‘mapped’ security model option.

Nowadays it would make sense to reimplement the proxy backend by using QEMU’s vhost feature, which would eliminate the high latency costs under which the 9p proxy backend currently suffers. However as of to date nobody has indicated plans for such kind of reimplementation unfortunately.

https://www.qemu.org/docs/master/about/deprecated.html#fsdev-proxy-and-virtfs-proxy-since-8-1

LXD uses virtfs-proxy-helper to isolate 9p filesystem shares to a user namespace to allow custom UID/GID mapping. This is required for the LXD multi-user mode to function safely.

LXD already supports exporting filesystem volumes to VMs using virtiofs, and uses virtiofsd in a user namespace too. However 9p filesystem shares are the only type of filesystem share that can be live migrated (unlike virtiofs shares). Additionally some guest OSes do not support virtiofs and only support 9p.

We will need to explore whether we can use the 9p local backend and potentially have to start QEMU itself in a user namespace, although that will almost certainly cause other issues we will need to try and workaround.

Other possibilities include dropping 9p filesystem share support entirely and use only virtiofs, but this would then mean guest OSes without virtiofs support wouldn't be able to access the agent config drive to start the LXD agent - so this would need some alternative solution (and ISO drive export perhaps?), and it would also mean that all filesystem volume shares would be disabled for guests that could be live migratable.

[tomponline]

Seeing these warnings in LXD VMs now:

qemu-system-x86_64:/var/snap/lxd/common/lxd/logs/block-test2/qemu.conf:273: warning: '-fsdev proxy' and '-virtfs proxy' are deprecated, use 'local' instead of 'proxy, or consider deploying virtiofsd as alternative to 9p

[SrNetoChan]

I am also getting this with a Windows 11 VM after I install virtio guest tools and tried to add a new disk device.

[simondeziel]

@kadinsayani reminded me of this ticking problem. It's also worse than with QEMU 8.x as support for this is dropped in QEMU 9.2+

This will cause problem soon as we'll try to move to the QEMU from the next LTS (26.04) and even Plucky (25.04) has moved past this version:

$ rmadison qemu-system-x86
 qemu-system-x86 | 2.0.0~rc1+dfsg-0ubuntu3  | trusty            | amd64, arm64, armhf, i386, powerpc, ppc64el
 qemu-system-x86 | 2.0.0+dfsg-2ubuntu1.46   | trusty-security   | amd64, arm64, armhf, i386, powerpc, ppc64el
 qemu-system-x86 | 2.0.0+dfsg-2ubuntu1.46   | trusty-updates    | amd64, arm64, armhf, i386, powerpc, ppc64el
 qemu-system-x86 | 1:2.5+dfsg-5ubuntu10     | xenial            | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 qemu-system-x86 | 1:2.5+dfsg-5ubuntu10.51  | xenial-security   | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 qemu-system-x86 | 1:2.5+dfsg-5ubuntu10.51  | xenial-updates    | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 qemu-system-x86 | 1:2.11+dfsg-1ubuntu7     | bionic            | amd64, arm64, armhf, i386, ppc64el, s390x
 qemu-system-x86 | 1:2.11+dfsg-1ubuntu7.41  | bionic-security   | amd64, arm64, armhf, i386, ppc64el, s390x
 qemu-system-x86 | 1:2.11+dfsg-1ubuntu7.42  | bionic-updates    | amd64, arm64, armhf, i386, ppc64el, s390x
 qemu-system-x86 | 1:4.2-3ubuntu6           | focal             | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:4.2-3ubuntu6.30        | focal-security    | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:4.2-3ubuntu6.30        | focal-updates     | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:6.2+dfsg-2ubuntu6      | jammy             | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:6.2+dfsg-2ubuntu6.24   | jammy-security    | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:6.2+dfsg-2ubuntu6.26   | jammy-updates     | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:8.2.2+ds-0ubuntu1      | noble             | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:8.2.2+ds-0ubuntu1.4    | noble-security    | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:8.2.2+ds-0ubuntu1.9    | noble-updates     | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:9.2.1+ds-1ubuntu5      | plucky            | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:9.2.1+ds-1ubuntu5.1    | plucky-proposed   | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:10.0.2+ds-1ubuntu2     | questing          | amd64, arm64, armhf, ppc64el, riscv64, s390x
 qemu-system-x86 | 1:10.1.0~rc2+ds-1ubuntu1 | questing-proposed | amd64, arm64, armhf, ppc64el, riscv64, s390x

[tomponline]

Yep I already notified @escabo @mionaalex and @skozina about this as a "must do" before next LTS and its on the spread sheet as such too.

[tomponline]

Although what the "do" entails is unclear at this point.

[tomponline]

Worst case is we drop 9p support entirely except for the read-only config drives (and export them directly via qemu).

[kadinsayani]

The local mode lets QEMU call VFS functions directly on the host. qemu specifies a security_model option to use with this mode:

security_model=mapped-xattr|mapped-file|passthrough|none: Specifies the security model to be used for this export path. Security model is mandatory only for "local" fsdriver. Other fsdrivers (like "proxy") don't take security model as a parameter. Recommended option is "mapped-xattr". passthrough: Files are stored using the same credentials as they are created on the guest. This requires QEMU to run as root and therefore using "passthrough" security model is strongly discouraged, especially when running untrusted guests! mapped: Equivalent to "mapped-xattr". mapped-xattr: Some of the file attributes like uid, gid, mode bits and link target are stored as file attributes. This is probably the most reliable and secure option. mapped-file: The attributes are stored in the hidden .virtfs_metadata directory. Directories exported by this security model cannot interact with other unix tools. none: Same as "passthrough" except the sever won't report failures if it fails to set file attributes like ownership (chown). This makes a passthrough like security model usable for people who run kvm as non root. https://wiki.qemu.org/Documentation/9psetup

The mapped model may work for us, but will require more investigation.

[simondeziel]

The mapped model may work for us, but will require more investigation.

If we keep 9p only for the config share, from the various available options, maybe none would also fit the bill. Testing/investigation required for sure.

[tomponline]

@mionaalex this is needed to work on before 6 LTS

[mionaalex]

@mionaalex this is needed to work on before 6 LTS

Ack, I remember discussions from before.