Linas Vepstas wrote: > But in my storage-key world, I can imagine spearating the strcture > from the data, and putting the structure in read-only memory, where the > app can see it but not corrupt it, and putting the data in a read-write > key, where the app can do whatever it wants.
And *once you have cleanly separated the two* (which is the diffcult part), why can't you just put them into two separate files, one of which is mmapped read-only? > In this kind of app, if you had to hide the data behind a socket, > I claim you would get performance roughly comparable to ordinary > file-io, and nowhere near the speed of memory-mapped io. In Linux, memory-mapped io is usually somewhat slower than file-io. (Both access the same page cache, but mmap in addition has to maintain all those page tables ...) There are of course some scenarios where mmap is faster, but mostly it is just more convenient. In any case, why would you use a socket when mmap is faster? Just use mmap, and use file access rights to protect the data. > Don't try to misunderstand me on purpose. Programmer A might be > be a very sophisticated developer of libraries, and able to go to > some lengths to do a good job. Programmer F might be trying to create > an app using A's library. But F is a ninny, and A would like to > protect against F's pratfalls, and maintain a semblence of > data integrity in the face of F's bad programming style. > Giving A a mechanism like storage keys gives A a chance to do well. But only if A manages to cleanly separate its data into different protection domains. Once this is done, there are any number of possibilities to enforce those, e.g. mmapping files with different access rights. > > > > One main point why just function calls are so much easier > > > > to use than IPC is that you can pass pointers to complex > > > > data structures back and forth. If you really implement > > > > some sort of strict memory protection, that won't work > > > > any more. > > > > > > Huh? why not? > > > > Because those pointers will point to memory the callee > > is not allowed to access? > > Huh? why not? 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. > What we did instead was to build some very special graphics hardware > that had the equivelent of storage keys in the hardware. To get > high performance, we doled out a key to a particular rectangular area > of the screen, and a client could doodle directly into the graphics > adapter memory all it wanted, at a very high performance. But if > it tried to write outside of the window boundary, well, too bad, > those pixels were masked off, and no damage was done. Sure, sometimes there are scenarios where specific hardware support helps you to implement a particular solution in an efficient and secure manner. (Usually, the problem was well-known before and hardware support designed specifically to solve it.) I do not doubt that you might find some problems where the S/390 storage keys could help. But I'm not convinced that any such solution will be significantly easier to implement and/or show significantly higher performance than solutions that could be implmented using the generic Unix protection mechanisms (separate processes, mmap, file access rights). In any case, I have still not quite understood just how the solution you are proposing is supposed to work. Could you give an example of a problem you want to solve, and how you would go about it? (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?) Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
