linux-kernel - Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support

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:	Tue, 7 Apr 2015 07:59:49 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Rob Clark <robdclark@...il.com>
Cc:	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

On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote:
> So, from a quick look, it seems like there is a lot of potential to
> split the v4l part out into some drm helpers.. it looks pretty
> generic(ish), or at least it could be with some strategically placed
> vfuncs in drm_v4l2_helper_funcs.
> 
> I do think we need to figure out the auth/security situation.  We
> probably don't want to let arbitrary processes open a v4l device and
> snoop on the screen contents.  We perhaps could re-use the dri2 drm
> auth stuff (v4l2_drm_get_magic ioctl?).  Or, well, it would be nice if
> the wb device could be made to not exist in /dev at all, and
> pre-open'd fd returned from an ioctl on the drm device, but not really
> sure if that is possible (or too weird).  Once the compositor process
> has the v4l device open and authenticated somehow, I expect it would
> use fd passing to pass the fd off to a trusted helper process.

Please don't resurrect the magic stuff ;-)

Anyway I discussed this a bit with Laurent and we figured the best way to
wire up writeback support is by using drm framebuffers. Then you can use
atomic flips to create a new snapshot. Of course that won't work with hw
where writeback is continuous, there v4l is a much better fit. And we also
have hardware where some v4l pipeline could directly feed into a drm
output pipeline, so we need a generic way to connect v4l and drm anyway.
For that I think we should add a new flag to addfb2 (or a new addfbv4l)
which creates a magic framebuffer from a v4l input/output. Some values
like stride don't make sense in such a virtual framebuffer, but pixel
format and size are all needed.

This way we don't need parallel abis for single-shot writeback directly
into framebuffers and for continuous writeback through v4l, we can reuse
the same drm framebuffer ones. And this also solves the security issues
since no one can start writeback without the drm device owner's consent,
so no need to reinvent anything there. And with atomic we already have
almost everything there: For the writeback framebuffer we only need a new
"WRITEBACK" property (which takes an fb id) and the small extension to
create v4l-backed framebuffers.

Cheers, 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/