Attendees:
Notes:
Agenda:
For today's meeting we'd like to discuss dma-buf heaps and the interaction with secure enclaves and also virtualized environments. In short, this is a continuation of an email from me to the TSC in August last year (subject: "dma_buf heaps - unmapped heaps").
As a bit of background we've already had two meetings in Q4 last year for the dma-buf/SDP use case, where we've had attendees from various companies interested in this. Topics discussed and the notes from those two meetings can be found here. Besides a general "kick-off" discussion, our initial goal has is to try to define the properties and requirements we need on the dma-buf heaps used for Secure Data Path use cases. I intend to use the same document to take notes for this particular call as well.
This meeting is not intended to take the place of the previously mentioned meetings. I intend to continue those as needed. However, we would like to see if we are able to get additional input from others. The attendees of the previous dma-buf/SDP meetings as well as a few others have been added to this invitation as optional attendees. Unfortunately I'm unable to make the time slot work for everyone because of the number of people who have been invited.
On the coding side, Google together with MediaTek have sent a couple patches upstream (most recent patch set can be found here).
There is a variety of challenges with this work, to name a few:
What are the properties we need for a secure heap?
What are the requirements we need for a secure heap?
Communication protocols? SDP involves basically all exception levels + boot as well as runtime. In theory we have various candidates, VirtIO, FF-A, Transfer List (Firmware handoff), Device Tree etc etc, to name a few.
What interfaces and APIs do we need from various runtimes?
Development platform where everything can be implemented and demonstrated.
Naming? There is some resistance to naming things "secure" from Linux kernel point of view. "Restricted" has been discussed as an alternative name.
Talking about this kind of work is made more difficult due to the fact that DRM technology is a controversial subject that some people find extremely offensive. So on top of the technical challenges we also need to consider this when having discussions with various communities.