Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbbHYHFa (ORCPT ); Tue, 25 Aug 2015 03:05:30 -0400 Received: from mail-wi0-f194.google.com ([209.85.212.194]:34060 "EHLO mail-wi0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750983AbbHYHF2 (ORCPT ); Tue, 25 Aug 2015 03:05:28 -0400 Date: Tue, 25 Aug 2015 09:05:23 +0200 From: Daniel Vetter To: Rob Clark Cc: Jilai Wang , linux-arm-msm , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" Subject: Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support (V2) Message-ID: <20150825070523.GH20434@phenom.ffwll.local> Mail-Followup-To: Rob Clark , Jilai Wang , linux-arm-msm , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" References: <93d3802305fa348738dae7f458c3fb56.squirrel@www.codeaurora.org> <1428430164-31874-1-git-send-email-jilaiw@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.2.0-rc1+ User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2426 Lines: 46 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). 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. -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/