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