Re: Linux xenfs vs privcmd

[Jürgen Groß <jgross@xxxxxxxx>]

On 08.10.25 15:33, Andrew Cooper wrote:
> Hello,
>
> I'm doing a deployment of Xen on a remote system provisioned with Ubuntu
> 24.04, and I've found what I'm pretty sure is a bug.
>
> In dom0, to start with:
>
> user@host:~$ ls -la /dev/xen/
> total 0
> drwxr-xr-x  2 root root     140 Oct  8 20:04 .
> drwxr-xr-x 18 root root    4620 Oct  8 20:04 ..
> crw-------  1 root root 10, 120 Oct  8 20:04 evtchn
> crw-------  1 root root 10, 118 Oct  8 20:04 gntalloc
> crw-------  1 root root 10, 119 Oct  8 20:04 gntdev
> crw-------  1 root root 10, 124 Oct  8 20:04 xenbus
> crw-------  1 root root 10, 123 Oct  8 20:04 xenbus_backend
> user@host:~$ ls -la /proc/xen/
> total 0
> dr-xr-xr-x   2 root root 0 Oct  8 20:04 .
> dr-xr-xr-x 326 root root 0 Oct  8 20:04 ..
>
> i.e. no /dev/xen/privcmd.
>
> It turns out that mounting xenfs causes it to appear:
>
> user@host:~$ sudo systemctl start proc-xen.mount
> user@host:~$ ls -la /dev/xen/
> total 0
> drwxr-xr-x  2 root root     180 Oct  8 20:05 .
> drwxr-xr-x 18 root root    4620 Oct  8 20:04 ..
> crw-------  1 root root 10, 120 Oct  8 20:04 evtchn
> crw-------  1 root root 10, 118 Oct  8 20:04 gntalloc
> crw-------  1 root root 10, 119 Oct  8 20:04 gntdev
> crw-------  1 root root 10, 115 Oct  8 20:05 hypercall
> crw-------  1 root root 10, 116 Oct  8 20:05 privcmd
> crw-------  1 root root 10, 124 Oct  8 20:04 xenbus
> crw-------  1 root root 10, 123 Oct  8 20:04 xenbus_backend
> user@host:~$ ls -la /proc/xen/
> total 0
> drwxr-xr-x   2 root root 0 Oct  8 20:05 .
> dr-xr-xr-x 315 root root 0 Oct  8 20:04 ..
> -r--r--r--   1 root root 0 Oct  8 20:05 capabilities
> -rw-------   1 root root 0 Oct  8 20:05 privcmd
> -rw-------   1 root root 0 Oct  8 20:05 xenbus
> -r--------   1 root root 0 Oct  8 20:05 xensyms
> -rw-------   1 root root 0 Oct  8 20:05 xsd_kva
> -rw-------   1 root root 0 Oct  8 20:05 xsd_port
>
> For good measure, I checked unmounting xenfs:
>
> user@host:~$ sudo umount /proc/xen
> user@host:~$ ls -la /dev/xen/
> total 0
> drwxr-xr-x  2 root root     180 Oct  8 20:05 .
> drwxr-xr-x 18 root root    4620 Oct  8 20:04 ..
> crw-------  1 root root 10, 120 Oct  8 20:04 evtchn
> crw-------  1 root root 10, 118 Oct  8 20:04 gntalloc
> crw-------  1 root root 10, 119 Oct  8 20:04 gntdev
> crw-------  1 root root 10, 115 Oct  8 20:05 hypercall
> crw-------  1 root root 10, 116 Oct  8 20:05 privcmd
> crw-------  1 root root 10, 124 Oct  8 20:04 xenbus
> crw-------  1 root root 10, 123 Oct  8 20:04 xenbus_backend
> user@host:~$ ls -la /proc/xen/
> total 0
> dr-xr-xr-x   2 root root 0 Oct  8 20:04 .
> dr-xr-xr-x 291 root root 0 Oct  8 20:04 ..
>
> and /dev/xen/privcmd stayed.
>
>
> Anyway - /dev/xen/privcmd (and /hypercall) shouldn't be tied to xenfs.
> They should be SIF_PRIVILEGED alone, should they not?
I don't think they should be tied to SIF_PRIVILEGED, as device model ops
are handled via the privcmd driver, too.

TBH I have no idea why there is a direct connection to xenfs.

Did you try to modprobe privcmd without mounting xenfs? I guess the
connection is that the capabilities in /proc/xen/capabilities are tested to
contain "control_d", resulting in the privcmd driver to be loaded.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature