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
