Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer

[Daniel Stone]

Hi Liviu,

On Wed, 18 Sep 2019 at 13:04, Liviu Dudau <Liviu.Dudau@xxxxxxx> wrote:
> On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > I totally agree. Framebuffers aren't about the underlying memory they
> > point to, but about how to _interpret_ that memory: it decorates a
> > pointer with width, height, stride, format, etc, to allow you to make
> > sense of that memory. I see content protection as being the same as
> > physical contiguity, which is a property of the underlying memory
> > itself. Regardless of the width, height, or format, you just cannot
> > access that memory unless it's under the appropriate ('secure enough')
> > conditions.
> >
> > So I think a dmabuf attribute would be most appropriate, since that's
> > where you have to do all your MMU handling, and everything else you
> > need to do to allow access to that buffer, anyway.
>
> Isn't it how AMD currently implements protected buffers as well?

No idea to be honest, I haven't seen anything upstream.

> > There's a lot of complexity beyond just 'it's protected'; for
> > instance, some CP providers mandate that their content can only be
> > streamed over HDCP 2.2 Type-1 when going through an external
> > connection. One way you could do that is to use a secure world
> > (external controller like Intel's ME, or CPU-internal enclave like SGX
> > or TEE) to examine the display pipe configuration, and only then allow
> > access to the buffers and/or keys. Stuff like that is always going to
> > be out in the realm of vendor & product-policy-specific add-ons, but
> > it should be possible to agree on at least the basic mechanics and
> > expectations of a secure path without things like that.
>
> I also expect that going through the secure world will be pretty much transparent for
> the kernel driver, as the most likely hardware implementations would enable
> additional signaling that will get trapped and handled by the secure OS. I'm not
> trying to simplify things, just taking the stance that it is userspace that is
> coordinating all this, we're trying only to find a common ground on how to handle
> this in the kernel.

Yeah, makes sense.

As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
the 'protected' flag on the resulting dmabuf?

Cheers,
Daniel