passing keys

[Jonathan Shapiro]

   Requiring transmitted keys to be contiguous could be a serious problem.
   In KeyKOS it was very common to pass two or three keys that in general
   couldn't be allocated together. It is expensive to rearrange keys to
   satisfy this requirement.

Charlie:

Point acknowledged.  Increasing the number of key slots induces some
complexity in DIMSUM, so I'ld be just as happy rid of it.  Let me
explain why I have in mind to change this, and perhaps we can work out
a better solution.

In my view, DIMSUM has to support emulated host environments very
well.  It will be a long time before people give up UNIX/Windows.
Both of these environments make heavy use of files, and it seems to me
that a process must hold a key for each open file.  I'm not partial to
memory mapped files in a distributed system, so I'ld prefer not to
have that be the primary mechanism for file access.

A UNIX process, even under the old model, is free to open up to 20
files simultaneously.  Many open ten at a time.  Add to this the
capabilities for the UNIX server, a file server or two, and the
process address space (so the process can call mmap), and things are
starting to look very tight at 16 keys.

If you buy this (and I grant that it may be wrong), then the rest
follows as consequential damage.  Key slot representations have to
grow, and in order to keep the message info in registers on processors
like the x86 one suddenly discovers that the message keys need to be
clustered.  The cure may well be worse than the disease.  If it proves
to be important, I'm more than willing to back off and pass key slot
names on the stack.

Things become more complicated when a small set of key registers is
shared by more than one thread.

While one can build a key bank domain and use it, the key bank process
imposes context switch overhead that worries me -- perhaps
unnecessarily.  My concern is TLB flushes (and on more and more
processors, cache flushes).  I'm prepared to believe that I'm
optimizing irrelevancies.  In reading over the nanokernel paper,
however, I've come to realize that the benchmarks described do not
stress certain parts of the UNIX emulator, and key banks seem to be
among them.

One could, I suppose, offer a user-level key bank as a trusted
abstraction much like the factory creator.  If the flushing proved to
be a big problem one could then move that into the kernel.  If you
view the key bank as a system service, you can even do the migration
on a platform by platform basis.

Clearly you understand these issues better than I, and I'ld welcome
your reactions.


Jonathan