Message-ID: <CAF6AEGvzkU=1rrSo6W4K0Bg9YZ=Lx_U=gtx_WSWawAYO-Q9bzA@mail.gmail.com>
Date:	Tue, 25 Aug 2015 15:11:12 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Rob Clark <robdclark@...il.com>,
	Jilai Wang <jilaiw@...eaurora.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support (V2)

On Tue, Aug 25, 2015 at 3:05 AM, Daniel Vetter <daniel@...ll.ch> wrote:
> On Wed, Aug 19, 2015 at 03:00:04PM -0400, Rob Clark wrote:
>> On Tue, Apr 7, 2015 at 2:09 PM, Jilai Wang <jilaiw@...eaurora.org> wrote:
>> So one thing that I wanted sorting out before we let userspace see
>> streaming writeback (where I do think v4l is the right interface), is
>> a way to deal w/ permissions/security..  Ie. only the kms master
>> should control access to writeback.  Ie. an process that the
>> compositor isn't aware of / doesn't trust, should not be able to open
>> the v4l device and start snooping on the screen contents.  And I don't
>> think just file permissions in /dev is sufficient.  You likely don't
>> want to run your helper process doing video encode and streaming as a
>> privilaged user.
>>
>> One way to handle this would be some sort of dri2 style
>> getmagic/authmagic sort of interface between the drm/kms master, and
>> v4l device, to unlock streaming.  But that is kind of passe.  Fd
>> passing is the fashionable thing now.  So instead we could use a dummy
>> v4l2_file_opererations::open() which always returns an error.  So v4l
>> device shows up in /dev.. but no userspace can open it.  And instead,
>> the way to get a fd for the v4l dev would be via a drm/kms ioctl (with
>> DRM_MASTER flag set).  Once compositor gets the fd, it can use fd
>> passing, if needed, to hand it off to a helper process, etc.
>>
>> (probably use something like alloc_file() to get the 'struct file *',
>> then call directly into v4l2_fh_open(), and then get_unused_fd_flags()
>> + fd_install() to get fd to return to userspace)
>
> Just following up here, but consensus from the lpc track is that we don't
> need this as long as writeback is something which needs a specific action
> to initiate. I.e. if we have a separate writeback connector which won't
> grab any frames at all as long as it's disconnected we should be fine. Wrt
> session handling that's something which would need to be fixed between
> v4l and logind (or whatever).

Was that consensus?  I agree that something should initiate writeback
from the kms side of things.  But if we don't have *something* to
ensure whatever is on the other end of writeback is who we think it
is, it seems at least racy..

> In general I don't like hand-rolling our own proprietary v4l-open process,
> it means that all the existing v4l test&dev tooling must be changed, even
> when you're root.

well, I know that, for example, gst v4l2src allows you to pass in an
already opened v4l dev fd, which fits in pretty well with what I
propose.  The alternative, I think, is a dri2 style auth handshake
between drm/kms and v4l, which I am less thrilled about.

I would have to *assume* that userspace is at least prepared to deal
with -EPERM when it tries to open a device..  at least more so than
special auth ioctl sequence.

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists