Re: [RFC] How implement Secure Data Path ?

[Thierry Reding <treding@nvidia.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4619 bytes --]

On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote:
> On Wed, May 06, 2015 at 11:19:21AM +0200, Thierry Reding wrote:
> > On Wed, May 06, 2015 at 10:35:52AM +0200, Daniel Vetter wrote:
> > > On Tue, May 05, 2015 at 05:54:05PM +0100, One Thousand Gnomes wrote:
> > > > > 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 ?
> > > 
> > > Iirc most of the dma api stuff gets unhappy when memory isn't struct page
> > > backed. In i915 we do use sg tables everywhere though (even for memory not
> > > backed by struct page, e.g. the "stolen" range the bios prereserves), but
> > > we fill those out manually.
> > > 
> > > A possible generic design I see is to have a secure memory allocator
> > > device which doesn nothing else but hand out dma-bufs.
> > 
> > Are you suggesting a device file with a custom set of IOCTLs for this?
> > Or some in-kernel API that would perform the secure allocations? I
> > suspect the former would be better suited, because it gives applications
> > the control over whether they need secure buffers or not. The latter
> > would require custom extensions in every driver to make them allocate
> > from a secure memory pool.
> 
> Yes the idea would be a special-purpose allocater thing like ion. Might
> even want that to be a syscall to do it properly.

Would you care to elaborate why a syscall would be more proper? Not that
I'm objecting to it, just for my education.

> > For my understanding, would the secure memory allocator be responsible
> > for setting up the permissions to access the memory at attachment time?
> 
> Well not permission checks, but hw capability checks. The allocator should
> have platform knowledge about which devices can access such secure memory
> (since some will definitely not be able to do that for fear of just plain
> sending it out to the world).

At least on Tegra there are controls to grant access to the VPR to a
given device, so I'd expect some driver needing to frob some registers
before the device can access a secure buffer.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel