Re: [Media Summit] ChromeOS Kernel CAM

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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