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
