From 71d72ececa086114df80fe4cc04d701b59002eb2 Mon Sep 17 00:00:00 2001 From: Christian Schoenebeck Date: Mon, 26 Jun 2023 13:49:06 +0200 Subject: 9pfs: deprecate 'proxy' backend As recent CVE-2023-2861 (fixed by f6b0de53fb) once again showed, the 9p 'proxy' fs driver is in bad shape. Using the 'proxy' backend was already discouraged for safety reasons before and we recommended to use the 'local' backend (preferably in conjunction with its 'mapped' security model) instead, but now it is time to officially deprecate the 'proxy' backend. Signed-off-by: Christian Schoenebeck Reviewed-by: Greg Kurz Message-Id: --- docs/about/deprecated.rst | 23 +++++++++++++++++++++++ docs/tools/virtfs-proxy-helper.rst | 3 +++ 2 files changed, 26 insertions(+) (limited to 'docs') diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 0743459..ddc1e48 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -343,6 +343,29 @@ the addition of volatile memory support, it is now necessary to distinguish between persistent and volatile memory backends. As such, memdev is deprecated in favor of persistent-memdev. +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +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 reimplemention unfortunately. + Block device options '''''''''''''''''''' diff --git a/docs/tools/virtfs-proxy-helper.rst b/docs/tools/virtfs-proxy-helper.rst index 6cdeedf..bd310eb 100644 --- a/docs/tools/virtfs-proxy-helper.rst +++ b/docs/tools/virtfs-proxy-helper.rst @@ -9,6 +9,9 @@ Synopsis Description ----------- +NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be +removed, along with this daemon, in a future version of QEMU! + Pass-through security model in QEMU 9p server needs root privilege to do few file operations (like chown, chmod to any mode/uid:gid). There are two issues in pass-through security model: -- cgit v1.1