With a support entitlement you can also get direct access to our team of highly-qualified Arm experts 24-hours a day
Open a support case
Consider a micro-kernel (not Linux) where device drivers are userland applications (PL0).
We would like to use DMA based device, like an Ethernet controller for example. To this mean, the micro kernel allocate some memory to the user application. In the past, we allocate Device Memory for this purpose, as a quick and dirty solution because we could only allocate normal cacheable memory or device memory. We recently changed that to allocate memory which is:
- Normal memory
Now some driver code is no longer working as expected. I'm pretty sure were are missing some memory barriers, but I'd like to know if our goal is achievable: can we use DMA with normal, non-cacheable memory (shared or not, any advice on the matter is welcome) without using cache maintenance operation.
If that matters, the CPU we are targeting are Cortex A9 (with PL310 L2 cache) and Cortex A7
you can use cashable memory but you have to care for flushing (before DMA) and flush/invalidate (after) the memory area.
That's exactly the opposite of what we are trying to do. We don't want to give access to cache maintenance operation to user programs, so we are wondering if we can instead use non cacheable memory.
Sorry,didn't pay enough attention (besides,why not let the kernel do it on behalf of the user code)
The problem with the non-cachable memory can be, that the write-buffer is active. So you might need a DMB before activating DMA.
To be able to protect against cache timing attacks & things like that we are trying to avoid as much as possible userland access to cache maintenance operations. This is a very specific security OS with precise needs, otherwise I won't even bother with a micro kernel in the first place :)
Thank you for the suggestion, we'll try to learn more about barriers & write-buffers !
To be able to protect against cache timing attacks & things like that
If you fear security breaches, isn't DMA a bad idea anyway? Unless you have a bus level MPU how do you want to hinder the user code to copy "secure" data via DMA? Most often DMA uses physical addresses, so the MMU does not stop it.
We are targeting boards with SMMU that can protect against DMA access
There should be no fundamental problem in doing this. Barriers might be all you need on the Cortex-A7.
On the Cortex-A9, though, you may have to follow a DSB with an L2C-310 Cache Sync operation to be sure it drains it's buffers.
Could you provide the name of the board with SMMU, thanks in advance.
Sorry I can't do that at the moment.
Thank you for the suggestion ! We'll investigate that soon. On cortex a7 we indeed were missing some DMB. Cortex A9 are next
It seems we don't have to sync the PL310, but I'm keeping this in mind if we ever encounter the same errors on such boards, since it might be just luck :)