Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 651668 - app-emulation/qemu: Create new udev file for VFIO devices
Summary: app-emulation/qemu: Create new udev file for VFIO devices
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo QEMU Project
Depends on: CVE-2018-7550
  Show dependency tree
Reported: 2018-03-27 04:09 UTC by nvinson234
Modified: 2018-03-27 16:15 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

65-vfio.rules (65-vfio.rules,100 bytes, text/plain)
2018-03-27 04:09 UTC, nvinson234
qemu-2.11.1-r53.ebuild (qemu-2.11.1-r52.ebuild,23.22 KB, text/plain)
2018-03-27 04:11 UTC, nvinson234

Note You need to log in before you can comment on or make changes to this bug.
Description nvinson234 2018-03-27 04:09:29 UTC
Created attachment 525638 [details]

This is a feature request.

Please add the attached udev file for VFIO devices to the qemu ebuild.  With default device permissions, VFIO device permissions are set up as:

    drwxr-xr-x 2 root root 80 Mar 25 18:38 /dev/vfio
    crw------- 1 root root 247,   0 Mar 25 18:38 /dev/vfio/1
    crw-rw-rw- 1 root root  10, 196 Mar 25 18:37 /dev/vfio/vfio

This is potentially unsafe as it allows any user to write to /dev/vfio/vfio.  It also restricts access to /dev/vfio/1 to root which prevents non-root users from performing vga-passthrough.  The attached rules file, however, alters the permissions to become the following:

    drwxr-xr-x 2 root root 80 Mar 25 18:38 /dev/vfio
    crw-rw---- 1 root kvm 247,   0 Mar 25 19:04 /dev/vfio/1
    crw-rw---- 1 root kvm  10, 196 Mar 25 19:04 /dev/vfio/vfio

This relaxes permissions on /dev/vfio/1 to allow any user of the kvm group to perform vga-passthrough.  Furthermore, it tightens the permissions on /dev/vfio/vfio to restrict access to only kvm users.

I believe this would be a better configuration as it removes the need to be root to perform vga-passthrough, and ensures access is restricted to users trusted to set up such VMs (i.e. users of the kvm group)
Comment 1 nvinson234 2018-03-27 04:11:35 UTC
Created attachment 525640 [details]

An updated version of the qemu-2.11.1-r52.ebuild.  The only difference between this one and -r52 is it includes the needed line to install the proposed vfio udev rules file.
Comment 2 Kash Pande 2018-03-27 04:33:49 UTC
yes, this is a pretty huge oversight and would be nice to correct the default settings.

i have reservation about the use of 'kvm' group since xen backend also works with vfio but i'm not sure that's the level of pedantic precision we should aim for.

another good idea would be to set the default group to 'kvm' in qemu.conf for libvirt, since otherwise it runs as root:root.
Comment 3 tdr 2018-03-27 06:26:23 UTC
Exposed pass-through devices with world writable bits should be tagged as a vulnerability.  Removal of those is a no-brainer.

Assigning kvm (or another) group as owner of the vfio node(s) aligns with the best practice of restricting the device while not requiring elevation to root.  Existing users may have rules in place already, so a post-emerge message would be appropriate.

That xen also uses the device vfio device node is brought up by comment #2.  While qemu and xen may be installed on the same system, it is probably is not common to do so.  It does leave the questions of whether a more universal group should be used for both virtualization methods and/or if the xen (or another) ebuild should be modified as well to keep ownership of the node consistent between methods.  Possible parent ticket for addressing vfio ownership on both virtualization platforms?

However vfio group ownership is modified, it + comment #2 regarding execution of libvert as kvm (or a virtualization) group would pair and nicely and easily move kvm support a notch forward with regards to security.
Comment 4 Matthias Maier gentoo-dev 2018-03-27 14:05:24 UTC
Confirmed. Starting any VM with PCI-passthrough, or simply modprobing vfio-pci
creates a device node with

    crw-rw-rw-  1 root root 10, 196 Mar 27 08:44 /dev/vfio/vfio

This is terrible. The default should be "crw-------".

I will add said rule to qemu immediately - but we should also investigate why modprobing vfio-pci creates the /dev/vfio/vfio device node with incorrect permissions.

CC'ing kernel, udev and security.
Comment 5 Larry the Git Cow gentoo-dev 2018-03-27 15:44:23 UTC
The bug has been referenced in the following commit(s):

commit 2fc1bc6c7b1f41a3a7df74ce8e170996eb7e36d9
Author:     Matthias Maier <>
AuthorDate: 2018-03-27 15:10:52 +0000
Commit:     Matthias Maier <>
CommitDate: 2018-03-27 15:44:04 +0000

    app-emulation/qemu: add rule to fix permissions on /dev/vfio/vfio
    The device node /dev/vfio/vfio gets created on modprobing the vfio*
    modules. This happens in particular on demand when a qemu vm with PCI
    passthrough is started up. The default permissios for the freshly
    created device node is
      crw-rw-rw-  1 root root 10, 196 Mar 27 08:44 /dev/vfio/vfio
    This is terrible.
    This patch adds an udev rules and makes sure that the device node has rw
    permissions for user root, and group kvm (and no permissions for all).
    This fixes
     - startup when a qemu-kvm is started as non-root (provided the user is
       in group kvm, which is our current policy for accessing /dev/kvm, etc.,
     - work around this security vulnerability, where /dev/vfio/vfio is
       created with world writable permissions upon modprobe. [1]
    Thanks to username234, Kash Pande, Ted Rodgers for discovery and patch!
    [1] Steps to reproduce:
        % ls -la /dev/vfio/vfio
        crw-------  1 root root 10, 196 Mar 27 15:40 /dev/vfio/vfio
        % modprobe vfio
        % ls -la /dev/vfio/vfio
        crw-rw-rw-  1 root root 10, 196 Mar 27 15:41 /dev/vfio/vfio
    [2] I cannot find an udev rule installed by libvirt/qemu/... that
        triggers these permissions.
    Package-Manager: Portage-2.3.24, Repoman-2.3.6
    RepoMan-Options: --force

 app-emulation/qemu/files/65-vfio.rules                              | 2 ++
 app-emulation/qemu/{qemu-2.11.1-r1.ebuild => qemu-2.11.1-r2.ebuild} | 1 +
 2 files changed, 3 insertions(+)}
Comment 6 Matthias Maier gentoo-dev 2018-03-27 16:15:28 UTC
According to the kernel documentation, mode 0666 is expected to be set because /dev/vfio/vfio alone does not provide any capabilities. Checked with other distributions [1].

Unassigning security and reverting.

Thanks to dwfreed for pointing this out.