Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755968AbbHYTLP (ORCPT ); Tue, 25 Aug 2015 15:11:15 -0400 Received: from mail-yk0-f174.google.com ([209.85.160.174]:33032 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755892AbbHYTLN (ORCPT ); Tue, 25 Aug 2015 15:11:13 -0400 MIME-Version: 1.0 In-Reply-To: <20150825070523.GH20434@phenom.ffwll.local> References: <93d3802305fa348738dae7f458c3fb56.squirrel@www.codeaurora.org> <1428430164-31874-1-git-send-email-jilaiw@codeaurora.org> <20150825070523.GH20434@phenom.ffwll.local> Date: Tue, 25 Aug 2015 15:11:12 -0400 Message-ID: Subject: Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support (V2) From: Rob Clark To: Rob Clark , Jilai Wang , linux-arm-msm , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3219 Lines: 65 On Tue, Aug 25, 2015 at 3:05 AM, Daniel Vetter 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/