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

[mripard at kernel.org]

On Fri, Jun 28, 2024 at 01:42:27PM GMT, Christian König wrote:
> Am 27.06.24 um 16:40 schrieb mripard at 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.

So you can always map and access the buffer, but only if you're in the
right "context" the content would be correct?

I think that part is pretty different than what ARM SoCs are doing,
where they would typically prevent any CPU access and fault on access.

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

I absolutely agree. I guess our discussion is whether it's something
that should be implicit and understood by applications, or if it should
be explicit and discoverable.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240628/a687e8be/attachment.sig>