Date: Thu, 16 Jan 2003 10:11:25 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@wemm.org>, Terry Lambert <tlambert2@mindspring.com>, "Alan L. Cox" <alc@imimic.com>, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <Pine.NEB.3.96L.1030116100226.59693C-100000@fledge.watson.org> In-Reply-To: <200301152051.h0FKpgxA009515@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Jan 2003, Matthew Dillon wrote: > I think we've established the usefulness of a VM Object descriptor. Now > what about the system call API? At the moment I have: Since we appear to be building a new API and IPC semantic from the ground up, I think it would be worthwhile to look at some of the other weird, wonderful, or perhaps just bizarre, things that others have done in the past. I know that NetBSD is in the throes of implementing Mach IPC, for example. Using an existing API (if we can find one that applies) would let us avoid the traditional pitfalls in IPC API design, of which there are many. For example, allowing us to pass VM object references using a Mach port primitive, or even ancillary data on a UNIX domain socket, would provide at least some of the features you're suggesting, but with a more familiar face. An additional advantage to looking at the Mach direction would be that we could pool resources with NetBSD to get Mach IPC up and running, and then when our PPC port is more off the ground, do Darwin emulation :-). At one point, speaking of ancillary data, I had some local hacks to allow kernel modules to register internalization and externalization calls for ancillary data transfer. I then hooked up modules that allowed processes to pass security tokens and capabilities to one another; providing similar support for passing around memory references would provide similar semantics to what you're describing, since the object could easily be an anonymous map from /dev/zero. I.e., (very, very pseudocode): fd = open(/dev/zero, O_RDWR); p = mmap(fd); uds = socket(UNIX); connect(uds, /var/run/app_rendezvous); sendmsg(uds, "memory attached", p); So I'm not saying a new API would be the wrong thing to do, I just want us to explore the options and see which has the lowest impact vs biggest bang. One concern I have with introducing entirely new primitives is how to fit them into the MAC Framework (i.e., are there new objects that require labels that didn't have labels before, how to document and instrument the important operations). Another concern is application portability -- we've actually had a lot of luck with other OS's picking up kqueue(), but IPC is likely to be more controversial, especially if it overlaps existing functionality provided by other IPC primitives. And, I'd like to avoid any further System V IPC debacles, where the semantics are such a poor match for UNIX that it's almost impossible to do useful security things with them. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030116100226.59693C-100000>