[PATCH v5 2/9] scatterlist: Add a flag for the restricted memory

[Christian König]

Am 28.06.24 um 15:40 schrieb mripard at kernel.org:
> [SNIP]
>>> So nobody can map that buffer, and the firmware driver is the one who
>>> knows that this buffer cannot be accessed by anyone.
>> On most hw I know you can actually map that buffer, it's just that the
>> CPU sees only garbage in it because you don't have the necessary
>> decryption keys around.
> So you can always map and access the buffer, but only if you're in the
> right "context" the content would be correct?

Exactly that, yes. You need to have access to the decryption keys.

> I think that part is pretty different than what ARM SoCs are doing,
> where they would typically prevent any CPU access and fault on access.

Yeah, that's indeed an important difference Nicolas noted as well.

>>> Putting this on the userspace to know would be pretty weird, and
>>> wouldn't solve the case where the kernel would try to map it.
>> But that's exactly how all other implementations work as far as I know. I
>> mean what do you do if the kernel maps the encrypted buffer?
>>
>> On AMD we also block userspace and kernel CPU accesses, but that is only
>> done to make it easier to find bugs not for correctness.
>>
>> And userspace absolutely needs to be aware that a buffer is encrypted, cause
>> otherwise it could potentially try to access it with the CPU.
> I absolutely agree. I guess our discussion is whether it's something
> that should be implicit and understood by applications, or if it should
> be explicit and discoverable.

Oh good point as well. But I think that's more a question for the 
userspace stack design.

E.g. it can be handled explicitly by the application itself or 
implicitly by some V4L or VA-API library or something similar.

For the kernel UAPI design we agreed at some point that we don't want to 
have any implicit properties on the DMA-buf which are carried around by 
the kernel, e.g. the whole format metadata for example.

One notable exception to this is the actual hw topology, e.g. when for 
example a device has a special interconnect to another device and you 
need to make sure that the devices are powered up and down in a specific 
order to make things work.

This should then made known to the core kernel using device link 
structure. E.g. similar to how it's used between GPU and HDMI audio 
block for example.

Regards,
Christian.

>
> Maxime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20240701/3f8b9fa8/attachment.htm>