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

[Nicolas Dufresne <nicolas@ndufresne.ca>]

Hi,

Le jeudi 27 juin 2024 à 16:40 +0200, mripard@kernel.org a écrit :
> > 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).
> 
> 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.

Userspace will be the one calling into the CDM TF-A to get the bitstream buffer
to be decrypted, not the firmware. The encrypted buffers are not using
restricted memory. Userspace is also responsible for calling into the MTK
restricted heap to allocate the destination buffer (on other platform it could
be CMA heaps + TF-A call to restrict the allocated memory, I've seen some
discussions related to this, but its not possible on Mediatek HW).

I think its fair to assume that userspace always know which buffers are
restricted or not in the SVP process.

Nicolas