Re: [PATCH v9 0/1] virtio-media: Add device specification

Demi Marie Obenour <[email protected]> Wed, 9 Jul 2025 15:48:56 -0400
Newsgroups	dev.linux.lists.virtio-comment
Message-ID	<[email protected]>
On 7/9/25 13:58, Nicolas Dufresne wrote:
> Hi Demi,
> 
> Le mercredi 09 juillet 2025 à 13:26 -0400, Demi Marie Obenour a écrit :
>> On 7/9/25 05:34, Albert Esteve wrote:
>>>
> [...]
> 
>>
>> It's probably too late, but I have some serious concerns about this
>> device.  Specifically:
>>
>> 1. I don't see a reasonable way to support untrusted virtio-media
>>    devices.  v4l2 has too many ioctls and I can't realistically
>>    see a way to enforce that the return values from all of them
>>    are consistent with each other.  It is possible to only allow
>>    a fixed format (such as uncompressed ARGB) and only allow the
>>    video source and/or sink to provide resolutions and frame rates,
>>    but this means losing a lot of performance and abandoning any
>>    attempt at zero-copy.
>>
>>    The use-case for untrusted virtio-media devices is not
>>    confidential computing, but rather disaggregated systems where
>>    video sources (like webcams) may be attached to untrusted virtual
>>    machines.
> 
> Please consider that you are posting broadly and understanding of what you mean
> by untrusted virtio-media can be difficult for non-virtio devs like me.

My use-case is this:

1. There is a VM that has all USB devices.
2. Some of those USB devices, like untrusted webcams, may be
   passed through to another VM via usbip.
3. The VM with the usbip device provides a video device to yet another VM.

The VM with the webcam and the VM receiving the video stream do not trust
each other.

> With the enclosed information, I believe implementer are not forced to map to a
> host V4L2 driver. You can implement a userspace layer in between, and possibly
> even implement reclaiming by simulation some hot-unplug of the devices, or by
> not scheduling any work for M2M.

I expect that any implementation that cares about security is going to do this.

> I don't really see the relation between "trust" and the pixel format selection.
> Nor why preventing zero-copy would help handling untrusted virtual machines. I
> do believe you should not attempt this if you don't have the required knowledge
> though, as its unlikely the end-result will be safe.

How can I validate the various parameters provided by a backend?

> For me the main issue for untrusted VM is the lack of control measure, such as
> cgroup for resource usage. This is being worked on though, Maxime Ripard have
> given an update at the Linux Media Summit in Nice.

Denial of service is not a concern in my use-cases.

>> 2. v4l2 is a chatty protocol and using it implies a lot of
>>    guest <=> host round-trips.  This is bad for performance.
>>    Is this overhead actually significant, and if so, are there
>>    plans to reduce it?
> 
> You should try and demonstrate this. Virtio Video tried to make their own and
> endup with something kind of similar with about the same level of back and
> forth. We already had few concerns with ioctl() overhead, and some measure have
> been implemented, notably s_ctrl_ext.
I'll leave this for later.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc (application/pgp-keys, 7 KB)
OpenPGP_signature.asc (application/pgp-signature, 833 B)