Re: capability interface for idl4

[Matthieu Lemerre]

"Neal H. Walfield" <address@hidden> 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.

I think that this is close enought to what we've already done to make
the step.  If I take, for instance, the declaration of 
hurd_pm_container_allocate:

error_t
hurd_pm_container_allocate (hurd_pm_container_t container,
                            l4_word_t start, l4_word_t size,
                            l4_word_t flags, l4_word_t *amount)

hurd_pm_container_t is a capability to a container.  (It is not the
case for now, but hurd_pm_container_t could be a pointer to a struct
containing both the capability handle and the communication end point
of the server).

>
>> 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.

You are right, these are two separate notions which need to be
separated.

I think that there are two types of objects:

* What you named "simple handle" would be better described as
  "authentification token".  The high-level operations which should be
  permitted on this object should be "map/grant/unmap".  Here is why:
  
  Imagine you have an authentificatioin token which gives access to a
  slot on a notification server (yes, this is a real example).  You
  then map this token to a server, so that it can send you a
  notification through the slot.

  Later, you don't need the server anymore, and you can just unmap the
  authentification token to reuse it somewhere else.

  If a copy operation is permitted, then a malicious server could copy
  the authentification token to another server, and then you could not
  do anything to revoke the right to use the authentification token to
  the other server.  You would have to ask the notification to revoke
  the right, which is most costly than a simple unmap operation.

* On the contrary, for capabilities a copy operation would be more
  appropriate.  For instance, a client wants to copy a capability to a
  container to a server to give it access to the container, so that it
  can fill it with data.  Cap is here an unnecessary third party if we
  have direct copy operation (but we don't do reference counting
  anymore if we do that).

So I think the two objects are semantically different.  However, one 
can be simulated in the other: you can copy objects by having a
mutually trusted third party when you have map/unmap, and you can do a
map operation by "wrapping" a capability when you have only copy.

So my point of view is that we could express the semantical operations
in the IDL, and find out what is the most appropriate with proper
benchmarks later (and do the necessary optimizations).

>> 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).

This is just the creation of a new capability.

In method int foo (cap interface io a, int x), Neal ommitted the in/out
parameter which we could use to determine if we would receive a new
capability or use an existing one.

When creating a new capability, the generated stub code would
allocate, in the implementation I wrote, a new cap box.  But there are
already problems: there are cases where we want the cap box to be
allocated with a notification token (to receive dead names
notifications), and maybe cases where we can't.

This is an example, but I don't see how we could make the distinction
without extending CORBA IDL (as described in the IDL4 reference
manual, I had problem retrieving capIDL for now).

Thanks,
Matthieu