Re: Just a few questions

[Justin Emmanuel]

Thanks for the prompt replies;

So let me get this right, if I hack an application (Capability A)and
take over execution with my virus the kernel should be able to identify
me as cap A. It should have  list of my rights somewhere so I shouldn't
be able to do any copying that I am not allowed to do by my kernel
designated rights. However if I then create a new process with copying
rights I can then get the system to copy my code with my newly created
capability or are Rights recursive? So that a child process can have no
more rights than than its parent?

Am I guessing correctly when I say that the kernel will ID a capability
by its memory location? Is this how the kernel knows what is what? In
that case what about RPC's? How can cross system procedure calls be
securely identified?

In Eros/Coyotos all processes are capabilities. Is this same
understanding being applied to this project?

>>2) How many capabilities can a capability have? 
>>
>??? Do you mean - how many capabilities can a *process* have? A
>process 
>can have any number of capabilities it gets/creats, untill it runs
>out 
>of its capability-space.

>??? Do you mean - how many *methods* can a capability have? It
>depends 
>on the interface that capability implements.

>I dont understand your question properly.

>From what I have seemed to grasp a capability is an atomic unit of
ability. Therefore it is system of controlling actions within a
names-space. (I could be completely wrong, this is just what I have
seemed to understand). Therefore a capability is an ID/Ability
combination. All internal processing within the process can be seen in
the normal method/attribute manner but any interaction with the system
then needs to be looked at in the ID/Ability way. This would probably
include all instantiations as they will each need there own ID/Ability
pair.

How can the system make sure that memory leakage is avoided? This is
particularly important with a persistent operating system.

I heard that the kernel should never be permitted to kill a process! Why
not? Particularly if a process has gone out of control. Whats the
thinking in that?



In Eros/Coyotos all applications are limited to an application-user
delimited name-space. If not a capability-user delimited name-space, an
idea that I think is particularly good. What is the projects leanings
towards this idea at current?

A LOT of work has been going on within the project and I here that there
are interesting ideas with regards to driver frameworks. Where can I get
information on this? I think that the idea of establishing standards is
the way to go, it will lead to longevity.



On Sun, 2005-10-23 at 08:56 +0200, ness wrote:
> [I answer the questions on my best knowledge, but that doesn't imply the
> answers have to be right]
> Justin Emmanuel wrote:
> > I just have a few questions, sorry if these have been addressed already
> > somewhere and I missed them, but I am curious. I have been listening to
> > Dr Shapiro's talks on Eros and it made me ask some questions.
> > 
> > 1) How can the a process/kernel know that a capability really is
> > who/what it says it is?
> 
> The kernel knows everything, so it has never a problem.
> The second question is more tricky. In the Hurd, a process cannot know
> that. It has to trust the soure of the capability. In EROS there is the
> possibility to identify a capability. I'm not sure how it works, but it
> has sth. to do with comparing caps, or so. We already had a discussion
> about this here.
> 
> > 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? 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?
> 
> A capability points to one object and has some rights associated with it.
> 
> > 3) Will L4 on Hurd be using a constructor capability?
> 
> First, we're not sure anymore whether we'll be allowed to say Hurd/L4.
> Maybye Hurd/Coyotos, maybye... Second, we had a lot of design changes
> last time. Only a few people have an imagination of how the Hurd on X
> will look like in the future. But I guess we will not adopt the
> constructor mechanism.
> 
> > 4) Does L4 have the answers to some of the questions raised by a project
> > like Eros?
> 
> The Hurd and EROS have different goals. The successor of EROS is coyotos.
> > 
> > Thanks for you patience. 
> >