headers
Matthieu Lemerre | 2 Oct 21:27
Picon
Favicon

Re: Meaning of IDL

"Jonathan S. Shapiro" <shap <at> eros-os.org> writes:

> Since this is a separate thread, I'm sending a second note with a
> different subject.
>
> We were surprised in CapIDL that the syntactic migration was small
> (aside: some of the OMG people have been talking with us about their
> next generation IDL). We did run into several areas where the two
> designs are solving different problems.
>
> 1. CORBA is designed to describe interfaces on servers, and there is an
> implicit assumption that the protocol has two big steps: (a) find the
> server, (b) speak on an interface.  In a capability system, you already
> have the interface descriptor, so step (a) is unnecessary. It also
> presents a complex set of security issues.
>
> 2. The CORBA model is client/server. The CapIDL model (and the
> capability model more generally) is client/interface. A client may hold
> multiple capabilities implementing distinct interfaces. It may turn out
> that these are all implemented by the same server process, but the
> client will not know this unless the server agrees to disclose it.
>
> This has minimal syntactic impact, but it is a significant conceptual
> deviation from CORBA. I'm curious whether a parallel deviation has
> occurred in HurdLand.
>

As Neal stated in the other thread, we haven't yet an interface
generator for Hurd/L4 (but we used MiG in the Hurd on Mach).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neal H. Walfield | 3 Oct 19:59

Re: physmem/README clarification

At Mon, 03 Oct 2005 21:21:11 +0530,
Joe Steeve wrote:
> <quote>
> 
> Frames are multiplexed

That is, a task has access to N frames and uses M pages where M is
possibly greater than N.

> as well as shared across multiple tasks,

Frames can be shared e.g. a la system V shared memory segments or they
can be shared much like libraries using copy on write techniques.

> it
> is useful to reallocate frames in place.  In this way, data
> structures are not torn down just to be immediately recreated and
> gratuitous COWs are not performed.  container_release
> disassociates frames in a region with any shared frames.
> 
> </quote>
> 

Consider a task which reads a 4kb block from a file.  The file system
(approximately) locks the user supplied container, allocates a frame,
reads the data from backing store into the frame and enters the frame
into its block cache (in the process marking the frame copy on write).
Finally, it unlocks the container and returns to the caller.  The
result is that the file system and the client both a copy on write
reference to the frame.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ness | 4 Oct 21:54
Picon
Gravatar

capability interface for idl4

To get the abstraction we need, there has to be an capability interface 
in idl4. This means, we can say idl4 "here is the cap, give it to xyz", 
and idl4 generates the stub. But I'm a little confused about what ways 
of sending caps we have and what is needed in idl4. I found the 
following ways of sending a capability:

1. simple handle passing
	We simply pass the handle for authentication. This means, the
	server we pass the handle provides the cap.

2. capability copying
	The process a has a handle to a cap provided by s and wants to
	give the process b the right to use this cap. This is done via
	the cap server.

3. sth. mysterious I called capability object passing
	The client calls a server and gets as result a newly created
	handle to a cap. Can e.g. be found in hurd_pm_container_create
	(better to see with the patches by racin).

Looks nice, but is this right this way? And, do we need the second one 
to be provided by idl4? I say, usually the server will not trust its 
client and this it's useless, as the server will not use the new handle.
--

-- 
-ness-
Permalink | Reply | 124 comments |
headers
Neal H. Walfield | 4 Oct 23:15

Re: capability interface for idl4

At Tue, 04 Oct 2005 21:54:50 +0200,
ness wrote:
> 
> To get the abstraction we need, there has to be an capability interface 
> in idl4. This means, we can say idl4 "here is the cap, give it to xyz", 
> and idl4 generates the stub. But I'm a little confused about what ways 
> of sending caps we have and what is needed in idl4. I found the 
> following ways of sending a capability:

Jonathan suggested something along the lines of:

  method int foo (cap interface io a, int x)

Which means that foo is a method which takes: a capability which
implements the io interface; and an integer x.  Note that this is
more strongly typed than, for instance, mig which cannot be taught
that only a port right which implements a particular interface should
be accepted.

> 1. simple handle passing
> 	We simply pass the handle for authentication. This means, the
> 	server we pass the handle provides the cap.
> 
> 2. capability copying
> 	The process a has a handle to a cap provided by s and wants to
> 	give the process b the right to use this cap. This is done via
> 	the cap server.
> 
> 3. sth. mysterious I called capability object passing
> 	The client calls a server and gets as result a newly created
(Continue reading)

Permalink | Reply | 123 comments |
headers
Matthieu Lemerre | 5 Oct 01:19
Picon
Favicon

Re: capability interface for idl4

"Neal H. Walfield" <neal <at> walfield.org> writes:

> At Tue, 04 Oct 2005 21:54:50 +0200,
> ness wrote:
>> 
>> To get the abstraction we need, there has to be an capability interface 
>> in idl4. This means, we can say idl4 "here is the cap, give it to xyz", 
>> and idl4 generates the stub.

I have been thinking lately and I came to the same conclusion.  I am
pretty sure that we could express interfaces between servers in some
way that could be rather independent of the microkernel.  This would
ease further porting : there wasn't much code to change in the servers
when using the new capability library than when using the old one, but
I think we could reduce this to no code difference at all.

>> But I'm a little confused about what ways of sending caps we have
>> and what is needed in idl4. I found the following ways of sending a
>> capability:
>
> Jonathan suggested something along the lines of:
>
>   method int foo (cap interface io a, int x)
>
> Which means that foo is a method which takes: a capability which
> implements the io interface; and an integer x.  Note that this is
> more strongly typed than, for instance, mig which cannot be taught
> that only a port right which implements a particular interface should
> be accepted.
(Continue reading)

Permalink | Reply | 101 comments |
headers
Ludovic Courtès | 6 Oct 14:40
Picon
Picon
Favicon

Re: capability interface for idl4

Hi Neal,

"Neal H. Walfield" <neal <at> walfield.org> writes:

> This is one of the reasons why the kernel needs to provide some form
> of support for capabilities.

That's an opportunity to resurrect an old thread...  ;-)

What do you think of Amoeba's relatively simple approach?
http://lists.gnu.org/archive/html/l4-hurd/2005-08/msg00014.html

Thanks,
Ludovic.
Permalink | Reply | 18 comments |
headers
Bas Wijnen | 6 Oct 18:21
Picon
Favicon

Re: capability interface for idl4

On Thu, Oct 06, 2005 at 02:40:13PM +0200, Ludovic Court?s wrote:
> Hi Neal,
> 
> "Neal H. Walfield" <neal <at> walfield.org> writes:
> 
> > This is one of the reasons why the kernel needs to provide some form
> > of support for capabilities.
> 
> That's an opportunity to resurrect an old thread...  ;-)
> 
> What do you think of Amoeba's relatively simple approach?
> http://lists.gnu.org/archive/html/l4-hurd/2005-08/msg00014.html

I think anything protected by sparsity is fundamentally flawed and
unacceptable, especially for something as critical as the kernel.

Of course I'm not the one whose acceptance it needs, though. ;-)

Thanks,
Bas

--

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

(Continue reading)






Permalink
| Reply
| 17 comments  
| 



  

  

  





headers


Simon Nieuviarts
 | 
7 Oct 13:05






Picon

Picon

Favicon





Re: capability interface for idl4


Le Jeudi 6 Octobre 2005 18:21, Bas Wijnen a écrit :
> On Thu, Oct 06, 2005 at 02:40:13PM +0200, Ludovic Court?s wrote:
> > Hi Neal,
> >
> > "Neal H. Walfield" <neal <at> walfield.org> writes:
> > > This is one of the reasons why the kernel needs to provide some form
> > > of support for capabilities.
> >
> > That's an opportunity to resurrect an old thread...  ;-)
> >
> > What do you think of Amoeba's relatively simple approach?
> > http://lists.gnu.org/archive/html/l4-hurd/2005-08/msg00014.html
>
> I think anything protected by sparsity is fundamentally flawed and
> unacceptable, especially for something as critical as the kernel.
>
> Of course I'm not the one whose acceptance it needs, though. ;-)

Hi,

I don't know the typical probability of a logical gate to erroneously flipping 
a bit. But I consider that if the the probability of such an hardware error 
is higher than the probability of a false sparsity match, then relying on 
this sparsity may be a right choice.
Anyway, not relying on sparsity at all (if possible) is still a better design. 
I'm not yet familiar enough with capabilities to know if it is possible.

Simon.






Permalink
| Reply
| 3 comments  
| 



  

  

  





headers


Ludovic Courtès
 | 
7 Oct 14:02






Picon

Picon

Favicon





Amoeba's approach to capabilities


Hi Bas,

Bas Wijnen <shevek <at> fmf.nl> writes:

> I think anything protected by sparsity is fundamentally flawed and
> unacceptable, especially for something as critical as the kernel.

I think I understand what you mean.  The problem is that I don't
understand how it relates to Amoeba's capability implementation,
summarized like this:

     A capability typically consists of four fields as illustrated in Fig. 2.
  1. The put-port of the server that manages the object
  2. An object number meaningful only to the server managing the object
  3. A rights field, containing a 1 bit for each permitted operation
  4. A random number, for protecting each object

(1) is a globally-unique identifier returned by the kernel, (2) is
computed by the server managing the object, and (4) is computed using a
secret random number known only to the server (the random number itself
is not part of the capability, unlike one might think from the above
description).

How _this_ is protected by sparsity?  Perhaps this is just a matter of
vocabulary.  However, my understanding of this is that capabilities are
computed using information known only to the server implementing them,
which makes it "hard" to forge new capabilities.

Maybe the whole difference is here: I consider that "hard" means "next
to impossible" (if you know that a given server implements an object on

(Continue reading)






Permalink
| Reply
| 12 comments  
| 



  

  

  





headers


Jonathan S. Shapiro
 | 
7 Oct 15:27






Favicon

Gravatar





Re: Amoeba's approach to capabilities


On Fri, 2005-10-07 at 14:02 +0200, Ludovic Courtès wrote:
> Hi Bas,
> 
> Bas Wijnen <shevek <at> fmf.nl> writes:
> 
> > I think anything protected by sparsity is fundamentally flawed and
> > unacceptable, especially for something as critical as the kernel.
> 
> I think I understand what you mean.

This note is in answer to Ludovic's question, but I think that it is
worth answering in a general framework.

Capability systems can be divided broadly into two types: protected and
unprotected.

A protected capability system is one in which the representation of a
capability is guarded by some form of partitioning. There are two common
methods for this partitioning:

1. Protection by separation, either by the OS, as in EROS, KeyKOS, and
Coyotos, or by the hardware as in the i432 or the fourth layer of the
original i960 architecture. In the OS form, the process uses an index
into an OS-maintained table (or equivalently: an address relative to an
OS-maintained capability address space).

2. Protection by a language runtime, as in Ree's W7 or (less strongly)
Java. Pointers in these systems cannot be fabricated arbitrarily from
data.


(Continue reading)






Permalink
| Reply
| 9 comments  
| 



  

  

  

  


  





    



Gmane