Re: [Media Summit] ChromeOS Kernel CAM

Laurent Pinchart
2022-09-08T14:15:07Z

On Thu, Sep 08, 2022 at 10:08:46AM +0200, Maxime Ripard wrote:
> Hi Ricardo,
>
> On Thu, Sep 08, 2022 at 09:11:11AM +0200, Ricardo Ribalda wrote:
> > > - Still on slide 16, V4L2 as an API is usable without disclosing vendor
> > > IP. What is not possible is upstreaming a driver. I don't see this as
> > > significantly different between V4L2 and the new API proposal. I
> > > expect this to be discussed on Monday.
> >
> > I am only considering upstream drivers. There is not much to discuss
> > for downstream or closed drivers :)
>
> Are we really discussing upstream *drivers*? If anything, it looks like
> the Kcam proposal moves most of the drivers out of upstream.

Given that the API proposal sets at a significant lower level than V4L2
in the stack, the concept of "userspace driver" (I meant it in the sense
of GPU support in mesa) plays a bigger role. It would be good to clarify
what is meant by "driver" and maybe use the term "kernel driver" when
only the kernel part is covered, to avoid misunderstandings.

> > > - Slide 31 mentions that entities can send operations internally and
> > > listen to each other events. I'd like to better understand how that
> > > will work without any abstraction in the API (as that is one of the
> > > main design decision behind this new API) when those entities are from
> > > different vendors, and handled by different drivers that are developed
> > > independently (for instance, the camera sensor and the CSI-2 receiver,
> > > or even the CSI-2 receiver and the ISP).
> >
> > It is still under work.
> >
> > Hardware, specially for standard buses, should be resilient (not
> > crash) to format mismatches. Otherwise a mal-functionling sensor or
> > too much noise could crash the system (with or without kcam).
> >
> > Drivers developed together should know about the rest of the system,
> > so that is not the issue here.
> >
> > For drivers developed by different vendors for a standard bus, on
> > hardware that is not resilient (that was a mouthful), then we need to
> > prepare a set of read-only standard registers.
>
> I'm not even sure that read-only registers would be enough. I've
> experienced first-hand DMA controllers that, when the camera has its
> timings completely off, end up completely confused and write way outside
> of its assigned buffer creating big chunks of corrupted memory in the
> system.
>
> And that was by writing fairly legit values to registers that were meant
> for that, so we wouldn't be able to defend against it even with the
> smartest whitelist.
>
> And we were in a "good faith" situation. Giving an attacker basically
> programmable access to DMA engines that might not be sitting behind an
> IOMMU seems like a very dangerous idea to me.

Do we need to preassign a range of CVE numbers ? :-)

> > > - Does the bike on slide 32 illustrate the difficult discussions we've
> > > had in the past and how progress was hindered ? :-)
> >
> > This is how we do code review at Google when two developers do not
> > want to work together. We take the bike to the rooftop and the two
> > developers that disagree tries to push the other developer to the edge
> > of the building.
> >
> > The first second, when you see your colleague falling you think that
> > you have won.... then you realise that you are falling with them.
>
> So the optimal solution would be that both stop pushing, or push the
> other just as hard without bulging? That doesn't seem like a good way to
> end up with a compromise ;)

--
Regards,

Laurent Pinchart