From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: "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>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Rob Clark <robdclark@gmail.com>,
Thierry Reding <treding@nvidia.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: Tue, 5 May 2015 17:54:05 +0100 [thread overview]
Message-ID: <20150505175405.2787db4b@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <CA+M3ks7=3sfRiUdUiyq03jCbp08FdZ9ESMgDwE5rgb-0+No3uA@mail.gmail.com>
> First what is Secure Data Path ? SDP is a set of hardware features to garanty
> that some memories regions could only be read and/or write by specific hardware
> IPs. You can imagine it as a kind of memory firewall which grant/revoke
> accesses to memory per devices. Firewall configuration must be done in a trusted
> environment: for ARM architecture we plan to use OP-TEE + a trusted
> application to do that.
It's not just an ARM feature so any basis for this in the core code
should be generic, whether its being enforced by ARM SDP, various Intel
feature sets or even via a hypervisor.
> I have try 2 "hacky" approachs with dma_buf:
> - add a secure field in dma_buf structure and configure firewall in
> dma_buf_{map/unmap}_attachment() functions.
How is SDP not just another IOMMU. The only oddity here is that it
happens to configure buffers the CPU can't touch and it has a control
mechanism that is designed to cover big media corp type uses where the
threat model is that the system owner is the enemy. Why does anything care
about it being SDP, there are also generic cases this might be a useful
optimisation (eg knowing the buffer isn't CPU touched so you can optimise
cache flushing).
The control mechanism is a device/platform detail as with any IOMMU. It
doesn't matter who configures it or how, providing it happens.
We do presumably need some small core DMA changes - anyone trying to map
such a buffer into CPU space needs to get a warning or error but what
else ?
> >From buffer allocation point of view I also facing a problem because when v4l2
> or drm/kms are exporting buffers by using dma_buf they don't attaching
> themself on it and never call dma_buf_{map/unmap}_attachment(). This is not
> an issue in those framework while it is how dma_buf exporters are
> supposed to work.
Which could be addressed if need be.
So if "SDP" is just another IOMMU feature, just as stuff like IMR is on
some x86 devices, and hypervisor enforced protection is on assorted
platforms why do we need a special way to do it ? Is there anything
actually needed beyond being able to tell the existing DMA code that this
buffer won't be CPU touched and wiring it into the DMA operations for the
platform ?
Alan
next prev parent reply other threads:[~2015-05-05 16:54 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 [this message]
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
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=20150505175405.2787db4b@lxorguk.ukuu.org.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=airlied@redhat.com \
--cc=benjamin.gaignard@linaro.org \
--cc=daniel.vetter@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®