Re: [Media Summit] ChromeOS Kernel CAM

Ricardo Ribalda
2022-09-08T18:14:32Z

On Thu, 8 Sept 2022 at 20:13, Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> On Thu, 8 Sept 2022 at 17:34, Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Thu, Sep 08, 2022 at 06:16:40PM +0300, Laurent Pinchart wrote:
> > > On Thu, Sep 08, 2022 at 04:59:05PM +0200, Maxime Ripard wrote:
> > > > On Thu, Sep 08, 2022 at 05:14:41PM +0300, Laurent Pinchart wrote:
> > > > > 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.
> > > >
> > > > I think there's a bit of a misunderstanding about what exactly is in a
> > > > DRM driver, and what is in Mesa.
> > > >
> > > > Mesa doesn't program the hardware at all, it's merely a glorified
> > > > compiler. It's not more of a driver than GCC is an OS. Most importantly
> > > > for our discussion, Mesa doesn't perform any kind of register access (or
> > > > register access request), only the (kernel) driver does that.
> > >
> > > Mesa compiles shaders, but also more generally produces command streams
> > > that are passed as blobs to the DRM driver, which then forwards them to
> > > the device with as little processing and validation as possible (when
> > > the device is designed with multi-clients in mind, that processing and
> > > validation can be reduced a lot).
> >
> > That's true, but at no point in time is the CPU ever touches that
> > command stream blob in the case of DRM...
>
> As Laurent says, the latest hardware is very similar to GPUs, you pass
> a set of commands to a firmware that does the actual R/W to the
> hardware.
>
> For hardware that is a register set, the vendor should have a good
> idea about what kind of validation should be needed: raw access (deny
> list) or more abstracted (allow list).
>
> The most critical part is the DMA, and that will always be abstracted.
> Also I doubt that we will have new hardware without an IOMMU, so we
> have the same layers of security as today.
>
> >
> > > Recent ISPs have a similar architecture, with a set of registers used
> > > to communicate with the ISP firmware, and then most of the hardware
> > > registers for the actual image processing blocks being programmed
> > > based from the command stream. "Command stream" may not be a very good
> > > term for ISPs as it's not really a stream of commands, but
> > > conceptually, we're dealing with a blob that is computed by userspace.
> >
> > ... while in Kcam, the CPU knows and will interpret that command stream.
> > Maybe not in all cases, but it's still a significant difference.
> >
> > If we had to draw a parallel with something else in the kernel, it looks
> > way more like eBPF or the discussion we had on where to parse the
> > bitstreams for stateless codecs.
> >
> > The first one has been severely constrained to avoid the issues we've
> > raised, and we all know how the second one went.
>
> In eBPF, you are moving some user code to the kernel, with an unstable API.
>
> In KCAM, (and in DRM), you let the user build a set of operations,
> that you pass to the kernel via a stable API, then it is validated and
> scheduled by the kernel.
>
> X11 was much more bizarre, the GPIO iomem was remapped into userspace.

s/GPIO/GPU/ ;)
>
>
>
>
> --
> Ricardo Ribalda

--
Ricardo Ribalda