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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Sep 2019 22:30:12 +0100
From:   Daniel Stone <daniel@...ishbar.org>
To:     Liviu Dudau <Liviu.Dudau@....com>
Cc:     Daniel Vetter <daniel@...ll.ch>, Ayan Halder <Ayan.Halder@....com>,
        "maxime.ripard@...tlin.com" <maxime.ripard@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "airlied@...ux.ie" <airlied@...ux.ie>, nd <nd@....com>,
        "sean@...rly.run" <sean@...rly.run>
Subject: Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer

Hi Liviu,

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