Linas Vepstas wrote: On Sat, Nov 09, 2002 at 08:01:55PM +0100, Ulrich Weigand was heard to remark: >> Just use mmap, and use file access rights to protect the data. > >How can a library get read-write access to a file, while preventing >the app from writing to the same file?
Of course you need two processes, that's my point: different access rights means different processes. Once you have two processes, it is trivial; one process gets read-write access to the file, the other read-only. >> Because the library call has switched the PSW key, that was your >> whole point, wasn't it? So if the caller was able to access that >> memory, the callee (running with a different PSW key) won't be. > >OK, on this point, maybe I am indeed quite stupid. It has been years >since I last looked at the 390 instruction set. Can't one set a >read-only mode for selected PSW keys? Every page of memory has a storage key, which holds a key and a fetch-protection bit. If the fetch-protection bit is cleared, then anyone can read the page; if the fetch-protection bit is set, only code running with a PSW key equal to the page key can read the page. So I guess you could make pages read-only to everyone. Still, the question is whether read-only access is enough; a typical library function interface is: here's a buffer, please write some data into it. >OK, I presented a spcific example, from the land of graphics hardware, >from the mid 1990's, where these traditional unix solutions completely >failed. This is fine, but it is quite different from what you're suggesting here. These high-end graphics cards allow access to part of the video memory, however the access is still per-process. I.e. if you characterize access rights in the form 'X is allowed to do Y', then these mechanisms enable a finer-grained Y (instead of 'access video memory' only 'access this part of video memory'), while X is still the same: this process. Therefore it easily fits into the whole Unix access rights concept. What you propose is a finer-grained X (not 'this process' but 'this process while it is executing code mapped from this library'). This is what IMO is the core problem of this idea. To stay with your example: why didn't you change the system so that a process was allowed to directly access the (whole) video memory, but only why it was executing code from a special, trusted video library that ensured it didn't do anything it shouldn't? That would have been comparable ... >OK, take for example, the X11 server. Rip out the socket communications >part, and let the xlib calls call directly those routines that the >X11 server would call, after it decodes a bit of protocol it read from a >socket. > >> (I.e. which memory areas get what storage >> key, what's in them, what pieces of code run under which >> PSW key and/or mask, and at what places the keys are switched?) > >The psw key would switch at the xlib boundary. The memory that >is in the x-server would run under the x-server's key, while the client >would run under a different key. Yes, but what about the difficult questions? ;-) Where are the arguments passed and returned? Where does the stack reside, and is it switched at function call or not? [If yes, the standard C calling convention doesn't work any more -- what to use instead? If no, the program can potentially corrupt the library's stack or vice versa.] How to avoid tricking the xlib into doing bad things by passing incorrect arguments to it? I think in this particular example, those questions might be solvable, because the current design already has a clear separation in place. So you'd for example just continue to do the same validity checks on arguments that the X server currently does. Also, the data is currently already prepared for passing across a socket, so you don't need to pass complex data structures containing pointers; this means it would be easy to pass just a single data block across the protection boundary. But if you do that, you basically have exactly the same scenario as now, except that the read/write across the socket is replaced by a program call (plus possibly some other actions like stack switching; in fact you might even need to perform a system call to inform the kernel that you're now in another protection domain). So what does all this buy you? A context switch on Linux is already quite fast, and while a program call might be a bit faster, it is also a complex milli-coded instruction that takes hundreds of cycles AFAIK, so I'm not convinced this gets you a huge increase in speed ... (This holds even more if you do need a system call; a system call with or without a context switch takes about the same time, at least on S/390.) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
