[RFC]: shmem fd for non-DMA buffer sharing cross drivers

[Nicolas Dufresne]

Hi,

Le mardi 22 août 2023 à 19:14 +0800, Hsia-Jun Li a écrit :
> Hello
> 
> I would like to introduce a usage of SHMEM slimier to DMA-buf, the major 
> purpose of that is sharing metadata or just a pure container for cross 
> drivers.
> 
> We need to exchange some sort of metadata between drivers, likes dynamic 
> HDR data between video4linux2 and DRM. Or the graphics frame buffer is 
> too complex to be described with plain plane's DMA-buf fd.
> An issue between DRM and V4L2 is that DRM could only support 4 planes 
> while it is 8 for V4L2. It would be pretty hard for DRM to expend its 
> interface to support that 4 more planes which would lead to revision of 
> many standard likes Vulkan, EGL.
> 
> Also, there is no reason to consume a device's memory for the content 
> that device can't read it, or wasting an entry of IOMMU for such data.
> Usually, such a metadata would be the value should be written to a 
> hardware's registers, a 4KiB page would be 1024 items of 32 bits registers.
> 
> Still, I have some problems with SHMEM:
> 1. I don't want thhe userspace modify the context of the SHMEM allocated 
> by the kernel, is there a way to do so?
> 2. Should I create a helper function for installing the SHMEM file as a fd?

Please have a look at memfd and the seal feature, it does cover the reason why
unsealed shared memory require full trust. For controls, the SEAL_WRITE is even
needed, as with appropriate timing, a malicous process can modify the data in-
between validation and allocation, causing possible memory overflow.

https://man7.org/linux/man-pages/man2/memfd_create.2.html
File sealing
       In the absence of file sealing, processes that communicate via
       shared memory must either trust each other, or take measures to
       deal with the possibility that an untrusted peer may manipulate
       the shared memory region in problematic ways.  For example, an
       untrusted peer might modify the contents of the shared memory at
       any time, or shrink the shared memory region.  The former
       possibility leaves the local process vulnerable to time-of-check-
       to-time-of-use race conditions (typically dealt with by copying
       data from the shared memory region before checking and using it).
       The latter possibility leaves the local process vulnerable to
       SIGBUS signals when an attempt is made to access a now-
       nonexistent location in the shared memory region.  (Dealing with
       this possibility necessitates the use of a handler for the SIGBUS
       signal.)

       Dealing with untrusted peers imposes extra complexity on code
       that employs shared memory.  Memory sealing enables that extra
       complexity to be eliminated, by allowing a process to operate
       secure in the knowledge that its peer can't modify the shared
       memory in an undesired fashion.

       [...]

regards,
Nicolas