From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Thierry Reding <treding@nvidia.com>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Rob Clark <robdclark@gmail.com>, Dave Airlie <airlied@redhat.com>,
Sumit Semwal <sumit.semwal@linaro.org>,
Tom Gall <tom.gall@linaro.org>
Subject: Re: [RFC] How implement Secure Data Path ?
Date: Fri, 8 May 2015 20:18:43 +0100 [thread overview]
Message-ID: <20150508201843.3447049b@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20150508083735.GB15256@phenom.ffwll.local>
> dma-buf user handles are fds, which means anything allocated can be passed
> around nicely already. The question really is whether we'll have one ioctl
> on top of a special dev node or a syscall. I thought that in these cases
> where the dev node is only ever used to allocate the real thing, a syscall
> is the preferred way to go.
So you'd go for
fd = dmabuf_alloc(blah..., O_whatever) ?
Whichever I guess.. really we want open("/dev/foo/parameters.....") but
we missed that chance a long time ago.
The billion dollar question is how is the resource managed, who owns the
object, who is charged for it, how to does containerise. We really ought
to have a clear answer to that.
> > I guess the same kind of logic as with GEM (except preferably without
> > the DoS security holes) applies as to why its useful to have handles to
> > the DMA buffers.
>
> We have handles (well file descriptors) to dma-bufs already, I'm a bit
> confused what you mean?
I was agreeing with your argument - with GEM as an example that it works
for the CPU accessing case.
Alan
next prev parent reply other threads:[~2015-05-08 19:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 15:39 Benjamin Gaignard
2015-05-05 16:27 ` Christoph Hellwig
2015-05-06 0:50 ` Laurent Pinchart
2015-05-06 8:37 ` Daniel Vetter
2015-05-05 16:54 ` One Thousand Gnomes
2015-05-06 8:35 ` Daniel Vetter
2015-05-06 8:49 ` Hans Verkuil
2015-05-06 9:19 ` Thierry Reding
2015-05-06 13:15 ` Daniel Vetter
2015-05-07 13:22 ` Thierry Reding
2015-05-07 13:52 ` Daniel Vetter
2015-05-07 16:40 ` One Thousand Gnomes
2015-05-08 8:37 ` Daniel Vetter
2015-05-08 8:55 ` Enrico Weigelt, metux IT consult
2015-05-08 19:18 ` One Thousand Gnomes [this message]
2015-05-12 8:46 ` Benjamin Gaignard
2015-05-06 9:22 ` Benjamin Gaignard
2015-05-06 11:29 ` Rob Clark
2015-05-07 14:41 ` Thierry Reding
2015-05-06 8:46 ` Benjamin Gaignard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150508201843.3447049b@lxorguk.ukuu.org.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=airlied@redhat.com \
--cc=benjamin.gaignard@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=sumit.semwal@linaro.org \
--cc=tom.gall@linaro.org \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®