2024-01-17 LTF - dma_buf Secure Heaps
- Grant Likely
- Joakim Bech
Date and Time: Jan 17, 2024 15:00 GMT
Connection details for the Zoom meeting:
https://zoom.us/my/joakimbech?pwd=M3JMbnhhQS92UFJUV3Y5VDJXbmd4Zz09
Meeting ID: 486 215 4756
Password: 13371337
Attendees
Alex Elder
Andy Harker
Arnd Bergmann
cgoldswo
Dan Handley
Deepti Jaggi
Don
Drew Reed
Fred Gylys-Colwell
Gen Shimada
Grant Likely
Jeff Kardatzke (Google)
Jens Wiklander
Jerome Forissier
Jerome Forissier
Joakim Bech
Jonathan Cameron (Huawei)
Kangkang Shen
Kiyoshi Owada (Socionext)
Leonardo Garcia
Linus
Mathieu Poirier
Mike Holmes
peter.zhang
Prakash Gupta
Prakash Gupta
Prasad QC (shreyanash)
Sebastian Ene
Srini
Sudarshan Rajagopalan
Sukadev Bhattiprolu
Sumit Semwal
Thomas Gall
Tim Benton
T.J. Mercier
Viktor Mårtensson (Google Pixel 7a)
Vincent Guittot
Agenda
Linaro Technical Forum
Recordings
Purpose and target audience
Future invites
How to get invited.
Meeting URL will change.
dma-buf and secure heaps
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").
Background: 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).Challenges: 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 runtime environments?
Development platform where everything can be implemented and demonstrated.
Naming conventions? 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.
Topics for today
Execution environments?
We’ve been very focused on things running on the host user space ↔︎ Linux kernel ↔︎ TrustZone (traditional TEE environment, OP-TEE, Trusty etc). What about other execution environments?
Virtualized environments: pKVM? Infotainment in Automotive?
Secure enclaves: What other secure enclaves should we consider?
Memory carveout
Currently a predefined area know to firmware and the OS.
As of know DT has been used to transfer information between execution stages. Transfer list is likely a future candidate.
The issue here is that it’s a hardcoded thing for each and every device. How can that be avoided? Run-time queries?
How to contribute?
Linux:
Linux kernel mailinglist
Reviewers: Always needed.
Subsystem maintainers: Often too busy and also it seems like people submitting patches often getting stuck between maintainers. It looks like DeviceTree, TEE, dma-buf and DRM graphics maintainers all need to be on board.
OP-TEE
Post questions and patches here: https://github.com/OP-TEE/optee_os
Widevine
Mainly developed by Google themselves, so start by reaching out to them.
V4L2
???
Generally:
Send Joakim Bech <joakim.bech@linaro.org> an email to get included to the ad-hoc meetings.
Files, presentations and recording
Recording
Notes
Please see recording.
Chat
16:04:50 From Joakim Bech To Everyone:
16:26:35 From Dan Handley To Everyone:
Regarding terminology, "protected memory" was used in earlier Arm specifications relating to this.
16:40:27 From Alex Elder To Everyone:
This was why I asked about passing between VMs. Display and decrypt could conceivably be in different VMs.
16:45:15 From Alex Elder To Everyone:
Exactly what I was talking about, Fred...
16:45:20 From Alex Elder To Everyone:
Maybe I was not mistaken