Re: Just a few questions

[Justin Emmanuel]

OK got that, thanks. This clears up a few of the misunderstandings that
I had with the last email. Still trying to get my head around
capabilities.

"capabilities are kernel data structures in both L4.sec and
EROS/Coyotos. They cannot be forged by applications. So either you
*have* a capability to the hard drive or you do not. You cannot "invent"
one."


On Sun, 2005-10-23 at 13:54 -0400, Jonathan S. Shapiro wrote:
> On Sat, 2005-10-22 at 23:56 +0100, Justin Emmanuel wrote:
> > 2) How many capabilities can a capability have? E.G. A mouse pointer
> > capability loaded from a somewhere or other that also ( malevolently)
> > has the capability programed in to write to the hard drive?? Whats to
> > stop that happening?
> 
> I do not know how to answer the first part of your question, because it
> is unclear. I *think* the answer is:
> 
>   Every capability lets some set of operations be done on *one* object.
>   A process can have as many capabilities (or as few) as it needs.
>   Capabilities do not hold capabilities.
> 
> The answer to the second part is: capabilities are kernel data
> structures in both L4.sec and EROS/Coyotos. They cannot be forged by
> applications. So either you *have* a capability to the hard drive or you
> do not. You cannot "invent" one.
> 
> > Is the user requested to give permission every time
> > a particular I/O operation takes place? What if you have connected a
> > file system ( maybe a floppy, CD ROM) and wish to copy some directories,
> > will it ask for permission on every object?
> 
> No. By connecting the directories, the user has already given the
> authority. No further questions are asked.
> 
> The general rule in a capability system is:
> 
>   Authority grows from connectivity.
> 
> The bad news is that users need to learn to be careful about what things
> they connect. The good news is that it is relatively easy to build user
> interfaces that help users make good decisions about this, and a lot of
> active and promising research about how, specifically, to do so is now
> going on.
> 
> > 3) Will L4 on Hurd be using a constructor capability?
> 
> I do not know. Unless L4.sec chooses to provide a COPY operation, the
> guarantees of the constructor seem impossible to achieve.
> 
> > 4) Does L4 have the answers to some of the questions raised by a project
> > like Eros?
> 
> I am not sure if you mean "EROS has identified some challenges, has
> L4.sec answered them?" or "EROS has some problems, does L4.sec improve
> on them?"
> 
> In my opinion, L4.sec does answer many of the challenging problems that
> EROS identified. Not all of them, but many of them. This is not
> surprising -- many of the key ideas that differentiate L4.sec from L4
> were adapted from EROS. I think that the reverse is also true. Several
> of the architectural changes in Coyotos come from adapting ideas in L4.
> 
> I think when we discuss problems, we need to distinguish between issues
> of implementation (which can be fixed) and issues of architecture.
> Fixing an architecture problem creates compatibility issues.
> 
> There are definitely some architectural warts in EROS. Some are
> corrected in Coyotos. I have looked at these warts for a very long time,
> and in every case I have reached the conclusion that the warts cannot,
> in principle, be eliminated. In each case I can see designs that would
> reduce some particular wart, but only with the cost that a different
> wart comes up someplace else in the architecture. My conclusion at this
> point is that the requirements for secure and robust designs cannot all
> be satisfied perfectly at the same time; you can only choose which warts
> are acceptable for your needs. I expect that the warts in L4.sec will be
> very different from the warts in Coyotos, but there *will* be warts.
> 
> shap
> 
> 
> 
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd