Am 28.06.24 um 15:40 schrieb mripard@kernel.org:
[SNIP] 

      

        

          
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?

    

    

    Exactly that, yes. You need to have access to the decryption keys.

    

    

      
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.

    

    

    Yeah, that's indeed an important difference Nicolas noted as well.

    

    

    

      

        

          
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.

    

    

    Oh good point as well. But I think that's more a question for the
    userspace stack design.

    

    E.g. it can be handled explicitly by the application itself or
    implicitly by some V4L or VA-API library or something similar.

    

    For the kernel UAPI design we agreed at some point that we don't
    want to have any implicit properties on the DMA-buf which are
    carried around by the kernel, e.g. the whole format metadata for
    example.

    

    One notable exception to this is the actual hw topology, e.g. when
    for example a device has a special interconnect to another device
    and you need to make sure that the devices are powered up and down
    in a specific order to make things work.

    

    This should then made known to the core kernel using device link
    structure. E.g. similar to how it's used between GPU and HDMI audio
    block for example.

    

    Regards,

    Christian.

    

    

      

Maxime