l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Capability Authentication


From: Jonathan S. Shapiro
Subject: Re: Capability Authentication
Date: Tue, 25 Oct 2005 14:06:10 -0400

On Tue, 2005-10-25 at 14:19 +0200, Marcus Brinkmann wrote:
> 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.

I will answer your question below, but let me begin by saying that in
EROS and KeyKOS we would consider such an application to be very
dangerous and we would look for ways to subdivide it. Still, as you say,
this is not always possible.

> =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?

In EROS this was true, and an extra system call was needed to load these
capabilities into cap registers in order to usefully manipulate them. We
never observed this to be a major issue, and it was all hidden by the
IDL code.

However, the extra system calls *are* a nuisance, which is why Coyotos
has a per-process capability address space that can be more directly
referenced.

> Moreover, this scheme can't support more than 32 threads invoking CALL
> at the same time.

I think you must be imagining that the capability registers are shared
across threads. Threads do not share capability registers. Each thread
has 32 capability registers that are independent from any other thread.
So there is no such limitation.

>   I understand that EROS applications are
> single-threaded.

That has been our usual practice, for the sake of simplicity. It is not
a requirement.

> Are there any plans to rectify some of this in Coyotos?  Ie, by using
> a capability address space, for example?

It isn't as broken as you thought, but yes, Coyotos is changing some of
this in ways that will be useful for these cases.


shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]