Re: [virtio-dev] Re: [RFC PATCH v6] virtio-video: Add virtio video device specification

[Alexandre Courbot <acourbot@chromium.org>]

On Wed, Apr 26, 2023 at 1:04âAM Cornelia Huck <cohuck@redhat.com> wrote:
>
>
> [I'm replying here, as that seems to be the last message in the thread,
> and my reply hopefully catches everyone interested here.]
>
> To do a very high level summary, we have (at least) two use cases for
> virtio-video, that unfortunately have quite different requirements. Both
> want to encode/decode video, but in different environments.
>
> - The "restricted" case: Priority is on security, and the attack surface
>   should be kept as small as possible, for example, by avoiding unneded
>   complexity in the interface. Fancy allocations and management should
>   be avoided. The required functionality is also quite clearly defined.
> - The "feature-rich" case: Priority is on enabling features, and being
>   able to re-use existing V4L2 support is considered a big plus. Both
>   device and driver implementations will be implemented in a full OS
>   environment, so all kind of helpers are already available.

I should highlight that virtio-v4l2 does not require any more allocations or
management that virtio-video does. It's just a different way to pass the same
messages between guest and host.

>
> (This is not to say that one case does not care about functionality or
> security; it's mostly a case of different priorities and environments.)
>
> I had been hoping that it would be possible to find kind of a common
> ground between the two cases, but reading the thread, I'm not quite as
> hopeful anymore... if we really don't manage to find an approach to make
> the different requirements co-exist, a separate virtio-v4l2 device might
> be the way to go -- but I've not totally given up hope yet.
>
> Some remarks from my side:
>
> - I'm not totally convinced that counting words is always a good proxy
>   for complexity -- an interface might be simple on paper, but if the
>   actual implementation would need to be quite involved to get it right,
>   we'd again have a lot of opportunity for mistakes.
> - How much of v4l2 does actually need to be in the device specification
>   for a driver to make potentially good use of it? Sure, being able to
>   directly map to v4l2 really gives a huge benefit, but is there a way
>   to extract a subset that's not too complex, but can be easily wrapped
>   for interfacing with v4l2? (Both interface and functionality wise.)
>   Even if that means that a driver would need to implement some kind of
>   shim, a layer that easily maps to v4l2 concepts would still be much
>   easier to implement than one that needs to map two quite different
>   interfaces. [I'm really relying on the good judgement of people
>   familiar with the interfaces here :)]

The current prototype is eschewing some legacy V4L2 features, so we are already
in that spirit. Even with a V4L2 guest there will be some light shimming.

One extra step we could maybe take, if we are worried about having the whole
V4L2 API, is assign a virtio device ID to each kind of device (decoder,
encoder, camera, ...) and explicitly list which calls and features from V4L2
are allowed for this kind of device - anything else is invalid and must be
rejected by the host.

This would result in more spec and less flexibility as nobody could e.g. write
a camera device before we specify what a camera device can do.

But it would also unambiguously define the allowed functionality and set hard
boundaries as to what can be done, which may be one of Alexander's concerns. As
a bonus it will also spare the guest from having to detect what kind of video
device it is dealing with as the device ID will carry that information.

I don't think it is absolutely necessary, as this is already defined in the
V4L2 docs, and the host is under no obligation to support every V4L2 syscall -
it can just reject those it doesn't like, as many drivers do. But it could be a
way to mitigate concerns about the attack surface.

> - To which extent does security need to be baked into the device
>   specification? We should avoid footguns, and avoiding needless
>   complication is also a good idea, but while every new functionality
>   means more attack surface, it also enables more use cases. That
>   tension is hard to resolve; how much of it can we alleviate by making
>   things optional?
>
> I hope I have not muddied the waters here, but I'd really like to see an
> agreement on how to continue (with two different devices, if there is
> really no other way.)

That would be an ironic way to end up with more work when we expected to have
less, but ultimately it's your call. :)