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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 28.06.24 um 22:16 schrieb Nicolas Dufresne:
[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..
I'm mostly a reader of the thread here, but I'd like to avoid basic mistakes.
The buffer in question are "protected", meaning that the CPU HW does not have
access to the underlying pages (or zone in the case of Meditatek).

This is different from encrypted buffers, which don't need this level of
protection, as without the security key to decrypt them, their content is close
to random data.

Thanks for that clarification, this difference was absolutely not obvious.

In that case having a separate heap for this memory is indeed the easiest approach.

My question is still what would happen if the CPU tries to access this protected buffer? Or does the CPU not even have an address to do that?

Just out of curiosity, I mean the exporting heap should then somehow reject any attempt to mmap() or vmap() the buffer content.

Thanks,
Christian.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux