Camera virtualization in Spectrum

Camera virtualization in Spectrum

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 3311 bytes --]

Alyssa and I discussed several designs for camera support in Spectrum.
These included:

- USB passthrough
- virtio-media
- v4l2loopback and a guest agent

A custom PipeWire plugin in the guest is also an option.

USB passthrough has serious security problems: the guest can perform
actions like updating device firmware, and the guest also fully trusts
the device.  This means that it is only suitable for trusted guests
operating on trusted devices, which is less than great.

v4l2loopback is an ugly hack and neither Alyssa or I like it, so I
don’t think it is going to be the approach taken.  It has the advantage
of being fairly easy to implement and not requiring any device emulation,
which is why Qubes OS went this route, but Spectrum has infrastructure
for implementing complex virtio devices in a reasonably secure way,
thanks to using Rust rather than C for this.

This leaves virtio-media and a fully custom solution based on PipeWire.
During the discussion, the possibility of hardening virtio-media against
a malicious device was considered.  After the call, however, I found out
that while hardening the kernel side is definitely possible, it is also
insufficient.  The reason is that virtio-media, as currently implemented,
appears to be effectively V4L2 API passthrough, which would mean that the
device can respond to V4L2 IOCTLs however it wants.  Guest userspace will
almost certainly treat V4L2 IOCTL outputs as trusted, so hardening the
guest kernel would be of only limited value.  Adding validation in the
guest kernel driver would be an option, but it would add substantial
complexity.

Instead, I think it is necessary to add a media server.  This server
would expose a virtio-media output device to the VM with the camera,
and would expose a virtio-media capture device to all VMs on the system,
not just those authorized to receive video.  This is because camera
hotplug is not properly handled by at least Google Chrome, so I expect
other applications to also mishandle it.  Instead, a VM that does not
have camera permission can be given a camera that always records black,
as if the user had covered the camera.  PipeWire is the only existing
implementation of a media server I know of that allows custom media
devices to be implemented out-of-process, so it is the best choice I
know of.  PipeWire is also considered the future by the entire Linux
desktop community.

One other factor that I did not consider at all during the discussion is
the need to implement the XDG microphone and camera portals.  These
portals are based on PipeWire, and PipeWire cannot be directly used
across VMs.  This is partially because of security, but it is also
because PipeWire relies on SCM_RIGHTS file descriptor passing, eventfds,
and other Linux kernel APIs that do not work across the VM boundary.
Therefore, it is necessary to either run PipeWire in the guest, or run
a daemon in the guest that exposes the same interface PipeWire does.
All portals supported in Spectrum that prompt the user require a
Spectrum-specific implementation so that the prompt happens on the host.

Are there any better options?  This is *an* approach, which does not
mean it is *the best* approach.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Camera virtualization in Spectrum

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> Instead, I think it is necessary to add a media server.  This server
> would expose a virtio-media output device to the VM with the camera,
> and would expose a virtio-media capture device to all VMs on the system,
> not just those authorized to receive video.  This is because camera
> hotplug is not properly handled by at least Google Chrome, so I expect
> other applications to also mishandle it.  Instead, a VM that does not
> have camera permission can be given a camera that always records black,
> as if the user had covered the camera.  PipeWire is the only existing
> implementation of a media server I know of that allows custom media
> devices to be implemented out-of-process, so it is the best choice I
> know of.  PipeWire is also considered the future by the entire Linux
> desktop community.

I'm surprised that camera hotplug isn't handled properly, given things
like laptop camera switches and USB webcams.  How does it go wrong?

So you're proposing passing the camera through to a VM that runs a
PipeWire media server, and then exposes virtio-media outputs from that
media server to other VMs?

> One other factor that I did not consider at all during the discussion is
> the need to implement the XDG microphone and camera portals.  These
> portals are based on PipeWire, and PipeWire cannot be directly used
> across VMs.  This is partially because of security, but it is also
> because PipeWire relies on SCM_RIGHTS file descriptor passing, eventfds,
> and other Linux kernel APIs that do not work across the VM boundary.
> Therefore, it is necessary to either run PipeWire in the guest, or run
> a daemon in the guest that exposes the same interface PipeWire does.
> All portals supported in Spectrum that prompt the user require a
> Spectrum-specific implementation so that the prompt happens on the host.

It doesn't look like the Camera portal is something that
xdg-desktop-portal delegates to a backend either, so we don't have a
hook to do Spectrum-specific stuff like granting camera access in the
media server, unless we provide our own x-d-p implementation (not just a
backend)…  Would it be possible to hook into PipeWire in the guest
instead, perhaps, to do that?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Camera virtualization in Spectrum

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> This leaves virtio-media and a fully custom solution based on PipeWire.
> During the discussion, the possibility of hardening virtio-media against
> a malicious device was considered.  After the call, however, I found out
> that while hardening the kernel side is definitely possible, it is also
> insufficient.  The reason is that virtio-media, as currently implemented,
> appears to be effectively V4L2 API passthrough, which would mean that the
> device can respond to V4L2 IOCTLs however it wants.  Guest userspace will
> almost certainly treat V4L2 IOCTL outputs as trusted, so hardening the
> guest kernel would be of only limited value.  Adding validation in the
> guest kernel driver would be an option, but it would add substantial
> complexity.

I've just noticed from reading the cover letter[1] for the virtio-media
spec that it looks like virtio-video might still happen:

> There is some overlap with virtio-video in regards
> to which devices it can handle. However, they take
> different approaches, potentially making them
> the preferable choice for different scenarios.

Have you looked at virtio-video at all?

[1]: https://lore.kernel.org/virtio-comment/20250304130134.1856056-1-aesteve@redhat.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]