Re: Codezero v0.2 Capabilities

Bahadir Balban <[email protected]> Sun, 13 Dec 2009 13:48:00 +0200
Newsgroups gmane.os.hurd.l4
Message-ID <[email protected]>
Michal Suchanek wrote:
> 2009/12/7 Bahadir Balban <[email protected]>:
>> Let me give an example. If a thread has a capability to send an ipc message
>> to another thread, this is described by a capability with a unique capid,
>> and the whole capability structure may be read into userspace for
>> discovering its details. It is normally kept inside the kernel in the
> 
> This is imho the wrong thing to do and it is also a failure of some
> (incomplete) Viengoos system manual I read. By allowing the user to
> inspect the capability you remove transparency and make things like
> virtualization and capability proxies impossible to do without
> cooperation of the processes that run in the virtualized environment.
> 
> If you instead make capabilities opaque handles that can be used to
> invoke a service but can't be used in any other way you make proxies
> and virtualization transparent adding to the extensibility and
> modularity of your system. Of course, you better remember what
> capability implements what interface when storing them or design a
> call that identifies the interface implemented by a capability.
> 
> Thanks
> 
> Michal
> 

This is a good point. But the current set of capabilities I implemented 
are rather rigid in their definition. The kernel strictly defines the 
resources that it manages, and those capabilities are not really open 
for different implementations. I think I would prefer to keep the kernel 
interfaces to have well-defined behavior so this would not be a relevant 
requirement from a kernel interface point of view.

As a next step though, it might be a good experiment to see if userspace 
processes can provide their own user buffers to install custom 
capabilities. The kernel, then would not care about the capability 
details, only check them on behalf of the owner. Such user-defined 
capabilities could be invoked with an opaque, user-defined capability 
invocation protocol over the ipc call.

This would be closer to your suggestion I think, but it is not something 
I can spend time on. I would be willing to help if someone was 
interested to do it though.


-- 
Bahadir Balban