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

[Cornelia Huck <cohuck@redhat.com>]

[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.

(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 :)]
- 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.)