Am 27.06.24 um 16:40 schrieb mripard@kernel.org:

[SNIP]

Why can't you get this information from userspace?

Same reason amd and i915/xe also pass this around internally in the

kernel, it's just that for those gpus the render and kms node are the
same
driver so this is easy.

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).

Yeah, that's perfectly fine. At least the AMD encryption solution works exactly like that as well.

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.

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.

Regards,
Christian.


Maxime