<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 28.06.24 um 13:47 schrieb Thierry Reding: <blockquote type="cite" cite="mid:w3xcvakoytubud6dw4wxr6ntbe6uvfrldihnd26vai6uyyto6j@vcq7gizxolag">[SNIP] <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">The reason I ask is that encryption here looks just like another parameter for the buffer, e.g. like format, stride, tilling etc.. So instead of this during buffer import: mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, "restricted", 10)); mtk_gem->dma_addr = sg_dma_address(sg->sgl); mtk_gem->size = attach->dmabuf->size; mtk_gem->sg = sg; You can trivially say during use hey this buffer is encrypted. At least that's my 10 mile high view, maybe I'm missing some extensive key exchange or something like that. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> That doesn't work in all cases, unfortunately. If you're doing secure video playback, the firmware is typically in charge of the frame decryption/decoding, and you'd get dma-buf back that aren't accessible by the CPU (or at least, not at the execution level Linux runs with). </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Can you clarify which firmware you're talking about? Is this secure firmware, or firmware running on the video decoding hardware? </pre> <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. 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=""> Doesn't userspace need to know from the start whether it's trying to do secure playback or not? Typically this involves more than just the decoding part. You'd typically set up things like HDCP as part of the process, so userspace probably already does know that the buffers being passed around are protected. Also, the kernel shouldn't really be mapping these buffers unless explicitly told to. In most cases you also wouldn't want the kernel to map these kinds of buffers, right? Are there any specific cases where you expect the kernel to need to map these? I've been looking at this on the Tegra side recently and the way it works on these chips is that you basically get an opaque carveout region that has been locked down by secure firmware or early bootloaders, so only certain hardware blocks can access it. We can allocate from that carveout and then pass the buffers around. It may be possible to use these protected carveout regions exclusively from the DRM/KMS driver and share them with multimedia engines via DMA- BUF, but I've also been looking into perhaps using DMA-BUF heaps to expose the carveout, which would make this a bit more flexible and allow either userspace to allocate the buffers or have multiple kernel drivers share the carveout via the DMA-BUF heap. Though the latter would require that there be in-kernel APIs for heaps, so not too sure about that yet.</pre> </blockquote> Yeah as far as I can see that would be a perfectly valid use case for DMA-Buf heaps. One question here: How does the HDCP setup work on Tegra? From your comment I guess you pass most of the information through userspace as well. Or is there any info inside the DMA-buf for this? In other words would you also need to know if a buffer is then allocated from this special carveout? Thanks, Christian. <blockquote type="cite" cite="mid:w3xcvakoytubud6dw4wxr6ntbe6uvfrldihnd26vai6uyyto6j@vcq7gizxolag"> <pre class="moz-quote-pre" wrap="">Thierry </pre> </blockquote> </body> </html>