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

[Christian König]

Am 28.06.24 um 13:47 schrieb Thierry Reding:
> [SNIP]
>>> 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.
>> 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).
> Can you clarify which firmware you're talking about? Is this secure
> firmware, or firmware running on the video decoding hardware?
>
>> 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.
> 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.

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.

> Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20240628/472c8599/attachment-0001.htm>