On Fri, Nov 08, 2002 at 05:50:56PM +0100, Ulrich Weigand was heard to remark: > Linas Vepstas wrote: > > > Sorry I used the word semaphore. Using pipes & shmem is hard. Well, > > using them is easy, using them and creating something that's extenisble, > > maintainble, lacks race conditions and other bugs ... that's a lot > > harder. If it's so easy, why didn't ssh do it years ago? > > The hard stuff is to design your application so that it *can* > be separated into multiple protection domains. The actual > *implementation* of that separation via multiple processes > is easy (trivial in comparison).
Sorta. It depends. One should also distinguish between app developers and library developers. For example, and maybe this is a bad example, but we had a library developer who wanted to create the ultimate dBaseIII/foxbase comaptbile database library. The traditional problem with dbase is that if the app goes crazy, it corrupts not only the data, but the structure itself, making it hard/impossible to recover. 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. Part of the "power" of a dbase-like thing is that one memory-mapped the db file, and thus you could just pick through it. It was memory-mapped because this access was a *lot* faster (orders of magnitude, even on linux), than using ordinary file-io routines. 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. To get decent performance out of a database that's hidden behind a socket, you have to invent something like SQL, and that gets hard. Even a super-minature, homebrew query-object is still harder than just memory-mapping some data structure. Theres an analogous situation with languages that support persistent objects (e.g. python, or maybe some form of java). The problem becomes one of how can python (the language itself) save the object to a file, and resotre it later, without risking corruption from the app itself? This is solved in part by e.g. having a java vm which can't be corrupted (in theory) by plain-old java code. But back in the early days of java, there were all sort os applets that could break of of the JVM. (Since java today is used mostly for servlets, and since we implicitly trust servlets, this is less of a problem). But if you were a JVM, and you might be buggy, and you wanted to run an untrusted java applet, it sure would be nice to put the applets memory pool in a different storage key than the JVM, so that if it did try to break you, it couldn't write to your storage. I don't see how to turn this problem into a "I'll just use sockets to protect me" problem. > Security is hard, and trying to implement some sort of framework > that will allow even inexperienced programmers to magically > only produce secure code strikes me as somewhat naive ;-) 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. > > > 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? Socekts also have some severe performance problems in certain domains. For example, the XShm extension to X11 uses shared memory to communicate stuff (pixmaps) with the X server, in order to avoid a rather sever penalty of cramming it through a socket. By contrast, X11 itself was designed as a client-server system precisly in order to prevent one crazy window client from corrupting the entire display and all other windows. Imagine how much easier it would have been (it could be?) to implement a windowing system as a library, not as a client-server with the associated protocol, encode/decodde layers, yadda yadda, if one could only gaurentee that one crazy app wouldn't spoil the entire display. Sadly, this is almost a lament (I worked on X11 for years): storage keys, where wer't thou when you were needed? 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. (To be more precise,a well, the above is an oversimplification. See http://linas.org/linux/graphics.html) We went to all of these great lengths to avoid jamming data into a socket. This was not unusual in the early 90's : SGI poineered the technique, and HP, Sun, IBM and others all built similar devices. I am not sure how the PC companies do it today. But this is almost alt.comp.folklore ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
