On Tue, Jan 28, 2014 at 2:37 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > In working with ashmem and looking briefly at kdbus' memfd ideas, > there's a commonality that both basically act as a method to provide > applications with unlinked tmpfs/shmem fds. > > In the Android case, its important to have this interface to atomically > provide these unlinked tmpfs fds, because they'd like to avoid having > tmpfs mounts that are writable by applications (since that creates a > potential DOS on the system by applications writing random files that > persist after the process has been killed). It also provides better > life-cycle management for resources, since as the fds never have named > links in the filesystem, their resources are automatically cleaned up > when the last process with the fd dies, and there's no potential races > between create and unlink with processes being terminated, which avoids > the need for cleanup management. > > I won't speak for the kdbus use, but my understanding is memfds address > similar needs along with being something to connect with other features. > > > So one idea was maybe we need a new interface. Something like: > > int shmgetfd(char* name, size_t size, int shmflg); > > > Basically this would be very similar to shmget, but would return a file > descriptor which could be mapped and passed to other processes to map. > Basically very similar to the in-kernel shmem_file_setup() interface. > > (Thanks to Akashi-san for initially pointing out the similarity to shmget.) > > Of course, shmgetfd on its own wouldn't address the quota issue right > away, but it would be fairly easy have a limit for the total number of > bytes a process could generate, or some other limiting mechanism. > > > The probably more major drawback here is that both ashmem and memfd tack > on additional features that can be done to the fds. > > In ashmems' case it allows for changing the segment's name, and > unpinning regions which can then be lazily discarded by the kernel. > > For memfd, the extra feature is sealing, which prevents modification of > the file when its shared. > > In ashmem's case, both vma-naming and volatile ranges are trying to > address how the needed features would be generically applied to tmpfs > fds (as well as potentially wider uses as well) - so with something like > shmgetfd it would provide all the functionality needed. I am not aware > of any current plans for memfd's sealing to be similarly worked into a > generic concept - the code hasn't even been submitted, so this is too > early - but in any case, its important to note none of these plans for > generic functionality have been merged or even received with much > interest, so I do understand how a proposal for a new interface that > only solves half of the needed infrastructure may not be particularly > welcome. > > So while I do understand the difficulty of trying to create more generic > interfaces rather then just creating a new chardev/ioctl interface to a > more limited subset of functionality, I do think its worth exploring if > we can find a way to share infrastructure at some level (even if its > just due-diligence to prove if the more limited scope chardev/ioctl > interfaces are widely agreed to be better). > > Anyway, I just wanted to submit this sketched out idea as food for > thought to see if there was any objection or interest (I've got a draft > patch I'll send out once I get a chance to test it). So let me know if > you have any feedback or comments. The reason "kdbus-memfd" exists is primarily the sealing. We need a way to pass possibly large areas of memory from one process to another, without requiring any trust relation between the two processes; there cannot be an assumption about trusted vs. untrusted or creator vs. consumer; all variations must be able to mix in all combinations, and still be safe A sender of the message must be sure that the receiver cannot alter the message, the same way the receiver must be sure that the sender cannot alter the message content it just sent. It would be nice if we can generalize the whole memfd logic, but the shmem allocation facility alone, without the sealing function cannot replace kdbus-memfd. We would need secure sealing right from the start for the kdbus use case; other than that, there are no specific requirements from the kdbus side. Kay -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>