<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 28.06.24 um 15:40 schrieb <a class="moz-txt-link-abbreviated" href="mailto:mripard@kernel.org">mripard@kernel.org</a>: <blockquote type="cite" cite="mid:20240628-cuddly-brave-squid-e1cb22@houat">[SNIP] <pre class="moz-quote-pre" wrap=""></pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">So nobody can map that buffer, and the firmware driver is the one who knows that this buffer cannot be accessed by anyone. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> So you can always map and access the buffer, but only if you're in the right "context" the content would be correct?</pre> </blockquote> Exactly that, yes. You need to have access to the decryption keys. <blockquote type="cite" cite="mid:20240628-cuddly-brave-squid-e1cb22@houat"> <pre class="moz-quote-pre" wrap="">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.</pre> </blockquote> Yeah, that's indeed an important difference Nicolas noted as well. <blockquote type="cite" cite="mid:20240628-cuddly-brave-squid-e1cb22@houat"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:20240628-cuddly-brave-squid-e1cb22@houat"> <pre class="moz-quote-pre" wrap=""> Maxime </pre> </blockquote> </body> </html>