[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Capability Authentication
From: |
Marcus Brinkmann |
Subject: |
Re: Capability Authentication |
Date: |
Tue, 25 Oct 2005 14:19:58 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Fri, 21 Oct 2005 08:03:47 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> 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.
This leads me to a different question. Say a process has 1000 open
files. For many applications, this seems like an unreasonable number,
but if I search hard enough, I am sure I will find some applications
which do this. Or let's say it's a server and 100 sockets. Anyway,
it boils down to 1000 capabilities being in active use.
Where do you store them? It seems that you have to create a node
hierarchy to store so many capabilities. And every time you use one,
you have to copy it into one of the registers. This seems to require
a system call (looking at the implementation). Isn't that a bit of a
downer?
Moreover, this scheme can't support more than 32 threads invoking CALL
at the same time. I understand that EROS applications are
single-threaded.
Are there any plans to rectify some of this in Coyotos? Ie, by using
a capability address space, for example?
Thanks,
Marcus
- Re: The Perils of Pluggability (was: capability authentication), (continued)
- Re: Capability Authentication, Marcus Völp, 2005/10/13
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/14
- Re: Capability Authentication, Marcus Völp, 2005/10/17
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/17
- Re: Capability Authentication, olafBuddenhagen, 2005/10/18
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/18
- Re: Capability Authentication, olafBuddenhagen, 2005/10/20
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/20
- Re: Capability Authentication, Jonathan S. Shapiro, 2005/10/21
- Re: Capability Authentication,
Marcus Brinkmann <=
- Re: Capability Authentication, Jonathan S. Shapiro, 2005/10/25