Re: Linux xenfs vs privcmd

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/10/2025 2:54 pm, Jan Beulich wrote:
> On 08.10.2025 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?
> Why would you want to restrict e.g. a Linux stubdom usermode from making
> hypercalls? Aiui this would break e.g. qemu running there. (Whether the
> tying to xenfs makes sense I can't really judge. Without that something
> else would need to make the two entries appear.)

Hmm, good point about Linux HVM stubdom.

It's no secret that I've been wanting to kill xenfs for several years
now.  It's one best examples of the wrong tool for the job that's still
around and causing bugs in the Xen ecosystem.

Either way, what I'm trying to say is that the contents of /dev/xen/
should be unrelated to xenfs.

~Andrew