Bug 1907485

Summary:	/dev/vhost-vdpa-$N needs vhost_device_t selinux label
Product:	Red Hat Enterprise Linux 8	Reporter:	Jonathon Jongsma <jjongsma>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED ERRATA	QA Contact:	Milos Malik <mmalik>
Severity:	medium	Docs Contact:
Priority:	high
Version:	8.4	CC:	jasowang, lvrabec, mmalik, plautrba, ssekidde
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.4
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Feature: The /dev/vhost-vdpa-NNN files are labeled vhost_device_t Reason: The proper type for/dev/vhost-vdpa-NNN files is needed to support the libvirt feature Virtual data path acceleration (vDPA), otherwise the generic device_t type would be assigned. Result: vDPA works flawlessly using the device files.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-18 14:58:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1771450

Description Jonathon Jongsma 2020-12-14 15:52:56 UTC

/dev/vhost-vdpa-$N (where $N is an integer) is a device node for vDPA devices that was recently added to the linux kernel. These devices are intended to be used for e.g. wire-speed network devices in virtual machines. In implementing support for these devices in libvirt, we discovered that qemu is prevented by selinux from doing an ioctl on the device:

virsh # start vm 
error: Failed to start domain vm
error: internal error: qemu unexpectedly closed the monitor: 2020-12-11T10:48:54.353774Z qemu-system-x86_64: -netdev vhost-vdpa,vhostdev=/dev/fdset/1,id=hostnet0: vhost_set_owner failed: Inappropriate ioctl for device (25)
2020-12-11T10:48:54.353788Z qemu-system-x86_64: -netdev vhost-vdpa,vhostdev=/dev/fdset/1,id=hostnet0: failed to init vhost_net for queue
qemu-system-x86_64: ../net/vhost-vdpa.c:198: net_vhost_vdpa_init: Assertion `s->vhost_net' failed.


See bug #1771450 for full details.

When looking at other vhost devices in /dev, I notice that they have different selinux labels whereas vhost-vdpa-$N only has a generic device_t type:

$ ls -lZ /dev/vhost*
crw-------. 1 root root system_u:object_r:vhost_device_t:s0  10, 238 Dec 10 09:43 /dev/vhost-net
crw-------. 1 root root system_u:object_r:device_t:s0       510,   0 Dec  8 14:51 /dev/vhost-vdpa-0
crw-------. 1 root root system_u:object_r:vhost_device_t:s0  10, 241 Dec  7 09:03 /dev/vhost-vsock

If I manually change vhost-vdpa-0 to be a vhost_device_t type, then libvirt/qemu can successfully use this device.

So, it appears that the selinux policy should add new case for vhost-vdpa-$N file paths and assign them a vhost_device_t type.

Comment 1 Zdenek Pytela 2020-12-16 20:14:47 UTC

I've submitted a Fedora draft PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/517

While it is possible in SELinux policy to assign default file context to a regexp, regexps cannot be used in file transitions, so I made it for numbers 0 to 7.

Jonathon,

How many these devices can possibly exist, or what is the reasonable maximum so that we can enumerate files for transitions in selinux-policy?

Comment 2 Jonathon Jongsma 2020-12-16 22:36:01 UTC

From looking at the kernel code, I don't think there's really a practical limit on how many of the devices can possibly exist. As far as I can tell, the max ID is "1<<20". I suspect that 0-7 will be sufficient for most purposes, but I don't know for sure. Jason, do you know how many vdpa devices might be reasonable to expect?

Comment 3 jason wang 2020-12-17 03:05:01 UTC

(In reply to Jonathon Jongsma from comment #2)
> From looking at the kernel code, I don't think there's really a practical
> limit on how many of the devices can possibly exist. As far as I can tell,
> the max ID is "1<<20". I suspect that 0-7 will be sufficient for most
> purposes, but I don't know for sure. Jason, do you know how many vdpa
> devices might be reasonable to expect?

It would be good if we don't set a limit to that.

Current vDPA parent are all VFs that means we can have 256 vDPA devices.

In the future, when subfunction is enalbed it can support more than 10K instances.

Thanks

Comment 5 Zdenek Pytela 2020-12-17 18:57:03 UTC

Jonathon, Jason,

Thank you for the explanation. In that case, I will leave the PR as is, but we need to mention the limitation in release notes.

We can also think of a kbase and suggestion to use a systemd service for relabeling.

There is also restorecond service as a part of policycoreutils-restorecond, but I need to figure out first if it works for /dev fs.

Comment 6 Zdenek Pytela 2021-01-04 16:47:07 UTC

This commit needs to be backported:

commit a13a14223a6b19d2b2012676a06ed6a3d2f0ff50 (HEAD -> rawhide, upstream/rawhide, origin/rawhide, origin/HEAD)
Author: Zdenek Pytela <zpytela>
Date:   Wed Dec 16 20:37:26 2020 +0100

    Label /dev/vhost-vdpa-[0-9]+ as vhost_device_t

    Virtual data path acceleration (vDPA) is a new feature in libvirt.
    With this selinux-policy commit, a particular file context specification
    for the new device files were added to the policy, same as for other
    vhost entries in /dev.
    To support the change, a set of appropriate file transitions for instances
    number [0-7] were added to the dev_filetrans_all_named_dev() interface.

    Especially note that the VHOST_VDPA_DEV_MAX limit in kernel is set
    to "1 << 20". While the default file context specification in SELinux
    can be set using a regular expression, i. e. for unlimited number
    of interface names, the transitions need to be enumerated, so they are
    specified for numbers [0-7] only.

    Resolves: rhbz#1907485

Comment 16 errata-xmlrpc 2021-05-18 14:58:20 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1639