Hi David, On Fri, Jun 7, 2024 at 1:38 AM David Rheinsberg <[email protected]> wrote: > > Hi > > On Tue, May 28, 2024, at 7:13 PM, Jeff Xu wrote: > >> > Another solution is to change memfd to be by-default sealable, > >> > although that will be an api change, but what side effect will it be > >> > ? > >> > If we are worried about the memfd being sealed by an attacker, the > >> > malicious code could also overwrite the content since memfd is not > >> > sealed. > >> > >> You cannot change the default-seals retrospectively. There are existing > >> shmem-users that share file-descriptors and *expect* the other party to be > >> able to override data, but do *not* expect the other party to be able to > >> apply seals. Note that these models explicitly *want* shared, writable > >> access to the buffer (e.g., render-client shares a buffer with the display > >> server for scanout), so just because you can *write* to a shmem-file does > >> not mean that sharing is unsafe (e.g., using SIGBUS+mmap can safely deal > >> with page-faults). > >> > > If the other party is controlled by an attacker, the attacker can > > write garbage to the shm-file/memfd, that is already the end of the > > game, at that point, sealing is no longer a concern, right? > > No. If a graphics client shares a buffer with a graphics server, the client > is free to write garbage into the buffer. This is not unsafe. The graphics > server will display whatever the client writes into the buffer. This is > completely safe, without sealing and with a writable buffer. > > > If the threat-model is preventing attacker on the other side to write > > the garbage data, then F_SEAL_WRITE|F_SEAL_SHRINK|F_SEAL_GROW can be > > applied, in that case, default-sealable seems preferable because of > > less code change. > > Again, the threat-model is *NOT* concerned with writes. > > Graphics clients/servers are a good example where *ANY* data is valid and can > be processed by the privileged server. Hence, *ANY* writes are allowed and > safe. No need for any seals. Those setups existed way before `memfd_create` > was added (including seals). > > However, when windows are resized, graphic buffers need to be resized as > well. In those setups, the graphics server might call `ftruncate(2)`. If you > suddenly make shmem-files sealable by default, a client can set > `F_SEAL_SHRINK/GROW` and the privileged graphics server will get an error > from `ftruncate(2)`, which it might not be able to handle, as it correctly > never expected this to happen. >
The graphic buffer is a good example for shmem-files of not-sealable-by-default. Thanks for the details. -Jeff > Thanks > David
