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

[Alexander Gordeev <alexander.gordeev@opensynergy.com>]

On 25.04.23 18:04, Cornelia Huck 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.
>
> (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'm thinking about the latter as more like a "compatibility" case, but
the "feature-rich" is also a good name.

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

From our side I can say, that moving from the current state even to a
well-defined subset of V4L2 would require a lot of work, bring literally
zero advantages for our use-case, while bringing some disadvantages. I
think we had a good progress so far, we don't want to give up the
achievements and now this is a great opportunity to do even better
because our priorities will not collide anymore.

On the other side I don't think Alexandre and his team are really
interested in doing the extra work of clearly defining the subset of
V4L2, writing larger specifications, going through all the hassle with
making the guest pages sharing work (again) and supporting this case in
their driver for us for something that is planned to be a very simple
device and driver. Please correct me if I'm wrong here.

And even if they say they agree to do the work with us... I'm sorry, but
you can probably see, that our communication doesn't go smooth. My
emails are forgotten, our use-case is clearly not a priority for
Alexandre, my arguments seem to be considered as obstacles. If we have a
single device, we have to cooperate actively. I have a lot of doubts
that it is possible at the moment. In this case I'd prefer to just make
room for everybody. Maybe we'll cooperate in a fruitful way again later.
The priorities or use-cases might change, for example. For us this is an
opportunity to finally update the virtio-video driver against the latest
state and hopefully make it V4L2 compliant.

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

Well, I agree, that this is not the best possible benchmark. At least it
is simple. My idea was that our output as spec writers is words. I hope
at some point we'll have a better benchmark or just agree, that these
structures have a lot of completely irrelevant stuff and it is not
immediately clear, what is necessary and what is not. Maybe the number
of different definitions (structs, struct fields, enum members, defines,
etc) would be a better benchmark?

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

I don't have an answer at the moment unfortunately.

> - 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?

My opinion is that it is best to not compromise on security right from
the start and not give up what we already have. Because it is hard to
add it back later. It is best to define clear granular interfaces from
the beginning, use feature flags where possible and also have many
different devices. Then it is easy both to add features and to reduce
the attack surface by disabling them. No device, no problem. I think
V4L2 does too many things with no clear way of disabling various
features. Defining the stateful decoder and encoder interfaces is a
great thing. We can already benefit from this. But I can see, that this
work is not finished yet.

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

Thanks for your suggestions!

--
Alexander Gordeev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone: +49 30 60 98 54 0 - 88
Fax: +49 (30) 60 98 54 0 - 99
EMail: alexander.gordeev@opensynergy.com

www.opensynergy.com

Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
GeschÃftsfÃhrer/Managing Director: RÃgis Adjamah

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>