Re: Capability Authentication

[Jonathan S. Shapiro]

On Thu, 2005-10-20 at 16:17 +0200, Marcus Brinkmann wrote:
> At Thu, 20 Oct 2005 02:31:20 +0200,
> <address@hidden> wrote:
> > 
> > Hi,
> > 
> > > For example, process instantiaton (spawn or fork) requires many
> > > capability copies even in our current plans.  Creating new processes
> > > is an important operation in the EROS operating system to enforce
> > > confinement policies.

In KeyKOS, processes had a grand total of 16 capability registers, and
no capability address space. In EROS, we went to 32, but we didn't need
it often. Also, in practice, we will find that most of the capabilities
transferred are the capabilities associated with the "standard
environment" -- things like stdin/stdout and so forth. These can be
bundled into a single bundle that is transferred as a unit.

> > 
> > I see a flaw in this reasoning: If you start more processes due to a
> > finer grained design -- which is probably a Good Thing (TM) -- then the
> > individuall processes do less, so you need only few capabilities for
> > each one... We'd need to make the rest of the process startup *very*
> > efficient, to make it matter even for a "hello world" process. (Would be
> > desirable, but I doubt it is achievable.)
> 
> Within these reservations, I don't think your argument is quite right.
> The number of capabilities per operation may be fewer, but the number
> of operations also raises.

The increase in the number of IPCs is, in practice, offset by other
performance gains. We think we understand what is going on, and I will
try to explain it, but it's not a matter of certainty.

> My understanding is that process spawning in EROS is blazingly fast,
> and that a substantial number of capabilities is copied in the system
> throughout.  So, there you would have one design and implementation
> you could have a closer look at if you want to explore this.  Please
> let us know what you find.

I do not know that I would say "blazingly fast". When we did the last
comparative measurement, the constructor mechanism for process
fabrication was about 2/3 the latency of fork+exec.

shap