Hi Liviu,
On Wed, 18 Sep 2019 at 13:04, Liviu Dudau Liviu.Dudau@arm.com 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