*Draft* DIMSUM architecture paper available

[Bryan Ford]

>   2. "All invocations of system-implemented object[s] are
>   semantically atomic": 
>
>When I wrote that sentence I had comething else in mind, though.  It
>means that the caller may assume that operations performed on a given
>system object can be viewed as happening in some (unspecified) serial
>order.

That sounds reasonable, assuming this definition of "atomic".

>   2.4. To whom is a read-only slot read-only?  Does this mechanism provide
>   any security features, or is it just a convenicence?
>
>To everyone.  The holder of a key table key can change the mask at
>will.
>
>This is a small evolution of the earlier zero key register idea.  I
>wanted two key tables for other reasons, and to implement the zero key
>register I would have needed to tag them with different internal
>types.  By adding the mask I don't need to do that.  It's not intended
>as a security feature.

In that case I suspect this feature may cause more trouble than it's worth -
an extra load and bit-test every time you write a key, at any rate.
You could go with the zero key register approach,
and simply make slot 0 in _all_ key tables fixed at zero -
so, with respect to a given thread, slots 0 and 16 are zero key slots.

Or just don't directly support throwing keys away at all -
if the user wants to throw away a key, it can specify a slot that
it doesn't use for anything else.  But then the kernel loses
some opportunity for optimization - it must always write every slot.

>Here is the (contrived) example.  Consider a multithreaded program
>running in an emulated UNIX environment.  One key table holds the
>per-process authorities, such as address space, file system key, etc.
>The other is used by individual threads in order to have return slots
>for any system calls that they make (which are ultimately built on
>IPC).  The problem is that without seperate key tables the individual
>threads cannot make independent invocations, and without a shared key
>table they cannot easily manage things like a common open file table.
>The shared key table is read-mostly.

Good example - but here's a reason it might not hold up completely
as an argument for shared key tables.  Accesses to any shared resource
must, in general, be synchronized somehow.  If one thread wants to open
a file and deposit a new key in the shared key table, it must synchronize
with the other threads somehow in order to prevent collisions.
Even if it is only reading the shared key table (e.g. performing a file
access using one of the keys in the shared table), it probably still has
to synchronize with the other threads in some way to ensure that
some other thread doesn't invalidate or replace the key to that file
after the first thread has established its existence but before it has
had a chance to use the key.

In the KeyKOS "religion", as I understand it, the basic "standard"
inter-thread synchronization mechanism is IPC.  So presumably,
besides the threads using the shared key table, you'll need another thread
to act as a lock on the shared key table.  But since you can easily and
efficiently transfer keys with the lock/unlock requests, the "lock thread"
could simply be the permanent owner of the shared keys, and shared key
tables are no longer needed at all.

Of course, this assumes that IPC is the only synchronization option.
If the threads share an address space, they could instead use
user-level hardware synchronization primitives.  There are real
benefits to that approach (mainly performance), but you should keep in
mind the implications of moving away from the "pure KeyKOS approach"
and introducing secondary inter-thread synchronization mechanisms.
At the moment I'm just playing the role of devil's advocate. :-)

>   3. 16K message data limit:  Why the increase?  
>
>It almost sounds like you're advocating that I go the other way -
>towards the *smallest* page size - because of the interrupt issue.

I am. :-)  Actually, I'm advocating either going all the way one direction
or the other - either no limits, or the least-common-denominator.
I suspect that straddling the fence may give you most of the
disadvantages of both approaches, with few of the advantages of either.
(e.g. the kernel must deal with multiple page transfers _and_ user code must
have a separate mechanism to transfer large amounts of data.)

>   One obvious way around this would be to define one of the eight data bits
>   associated with any start key as the "read-only" bit.  (Or add a ninth bit
>   if there's room in the key.)  The kernel would automatically set that bit
>   when a sensory key is used to retrieve a start key.  The server can then
>   interpret that read-only bit in whatever way is appropriate for the type of
>   object it implements.
>
>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.

Ah, I see - that's interesting.  In that case I think KeyKOS sensory keys
were intended to serve quite a different purpose than what I originally
assumed.  I can see the usefulness of a "secure sensory key", in spite
of the violation of encapsulation it implies.

Actually, I think both kinds of sensory keys could, at least conceptually,
be seen as simply part of the "standard" object protocol that all
kernel-implemented objects, and some user objects, may implement.
The "insecure" sensory key could be supported by all objects as I already
described; the "secure" sensory key could be implemented in the same way,
except that such sensory keys must only ever point to objects in the 
trusted computing base (whether they be user or kernel), and an object
must enforce that rule when attempting to convert an arbitrary key to a
"secure sensory key" to be divulged to an untrusted entity.

				Bryan