On Wed, Jan 31, 2024 at 6:15 AM Joakim Bech <joakim.bech@xxxxxxxxxx> wrote: > On Fri, Jan 12, 2024 at 05:23:07PM -0800, John Stultz wrote: > > So we need some clarity in what "restricted" really means. For > > instance, it being not cpu mappable vs other potential variations like > > being cpu mappable, but not cpu accessible. Or not cpu mappable, but > > only mappable between a set of 3 devices (Which 3 devices?! How can we > > tell?). > > > Can we flip things around? I.e., instead of saying which devices are > allowed to use the restricted buffer, can we instead say where it's not > allowed to be used? My view has been that by default the contents of the > types of buffers where talking about here is only accessible to things > running on the secure side, i.e, typically S-EL3, S-EL1 and a specific > Trusted Application running in S-EL0. I guess that serves as some kind > of baseline. ? This seems like you're suggesting enumerating badness? I'm not sure I understand the benefit of that. > From there, things turns to a more dynamic nature, where firewalls etc, > can be configured to give access to various IPs, blocks and runtimes. > > I understand that it's nice to be able to know all this from the Linux > kernel point of view, but does it have to be aware of this? What's the > major drawback if Linux doesn't know about it? Indeed, it doesn't necessarily. The idea with DMABUF heaps is it provides a name to abstract/wrap a type of constraint. So you can then allocate buffers that satisfy that constraint. Admittedly the downside with DMABUF heaps is that it has a bit of a gap in the abstraction in that we don't have a mapping of device constraints, so in Android gralloc provides a device specific usage/pipeline -> heap mapping. (Note: This I don't think is very problematic - I often use the example of fstab as device-specific config everyone is comfortable with - but I know folks would like to have something more generic) I believe Christian has previously proposed to have the devices provide something like symlinks from their sysfs nodes to the heaps the device supports, which is an interesting idea to mostly close that issue. Applications could then scan the devices in a pipeline and find the type they all support, and the specific names wouldn't matter. However, I'd expect the same hardware pipeline might support both restricted and unrestricted playback, so there would need to be some way to differentiate for the use case, so I'm not sure you can get away from some heap name to functionality mapping. My main concern with this patch series is that it seems to want to bundle all the different types of "restricted" buffers that might be possible under a single "restricted" heap name. Since we likely have devices with different security domains, thus different types of restrictions. So we may need to be able to differentiate between "secure video playback" uses and "protected device firmware" uses on the same machine. Thus, I'm not sure it's a good idea to bundle all of these under the same heap name. thanks -john
