General comments on the comments:
> That said, for some devices they make sense, and the kernel would
> implement a stub driver that just handles diddling device registers.
This is what KeyKOS did with its device key. Of course, the 370 has channels, and not device registers, so the device key let you run channel programs. You may want to impliment something similar if your hardware has character level interrupts for some devices (e.g. UARTs).
> 2. "All invocations of system-implemented object[s] are
> semantically atomic":
>
> Can you flesh out exactly what this means a little more? For example, does
> it mean you can't interrupt an IPC operation in the middle and leave a
> partially-copied data buffer in the receiver?
>
> I don't intend to let transfers be interrupted in mid-stream, The
> kernel is free to buffer, but w.r.t any given process the transfer
> happens "instantaneously."
This question is much more complex than appears on the surface. Consider the cases of either a DMA device of an other CPU writting into the string while the kernel is copying it as part of an invocation. 370 Principles of Operation goes to great length to define how these situations are resolved in the hardware, even to defining the minimum size and alignment atomic writes.
> For simple services, I can't envision shared key tables being very
> useful (do you have a concrete example of how they would be?),
>
> As it happens, I'm not convinced that sharing key tables is a good
> idea either. On the other hand, I'm reluctant to toss the idea so
> quickly just because we don't se a good use for it now.
In KeyKOS, domains frequently make "clones" of themselves where all the keys are copied. (This results in a situation something like multiple threads in a UNIX process.) I can immigine that if KeyKOS supported 2 keys notes for a domain, the clone process would have given the clone domain a node key to one of them to save the cost of copying.
> Key registers are private to a thread in KeyKOS only by convention.
> The register node is seperate from the domain root and could, in
> principle, be shared. I don't know if it ever was in practice.
Never in practice. It would be expensive with the current kernel, but should still work.
> KeyKOS key spaces are implemented as processes, and carry a
> consequential context switch overhead.
There have been suggestions for having the kernel do the node tree walk involved in accessing a key space (aka Supernode). This idea remains just a suggestion for now.
> I haven't had occasion to talk
> through the merits of shared libraries for this sort of thing, but the
> KeyKOS system uses domains in many places where you or I might make
> use of shared libraries instead. Sometimes that has security
> benefits.
We found that many domains had performance advantages as the keys they need are in the registers and do not need to be fetched from a supernode. Your mileage may vary...
> KeyKOS does not have a disabled state. The disabled state is a
> placeholder until I figure out what debugging sequence points I want
> to stick into the state diagram. The basic idea is to freeze a
> process without thereby causing it's messages to be dropped on the
> floor.
KeyKOS used meters to freeze a process. You could use schedules.
> I'll have a look at that - it's a good idea, but I'm running out of
> bits. One issue is that a sensory key is intertwined with the
> security model; a sensory key can never be an outbound channel. Your
> proposed change probably breaks that, though I still think it's a
> reasonable idea.
One of the reasons capability systems got a reputation of being inherently insecure (Orange book style) is that the early ones has no way to limit the propergation of keys. The sensory key is the way propergation is limited in KeyKOS. Remember that a security goal of the Orange book is to keep a trojan horse program from stealing your secrets.
> I'm not happy with that notion either, and I'm perfectly open to
> tossing it. Can you describe how UNIX-on-Mach handles this issue?
> Also, can you tell me where I can read about the hurd approach? I'm
> trying to avoid routing all calls through a central server.
How about when a user logs on, the logon process builds an initial set of keys based on his user record in some (very private) database? (This is the problem that caused KeyKOS to implement persistance.)
Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz@netcom.com Los Gatos, CA 95032, USA