[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Codezero v0.2 Capabilities

From: Bahadir Balban
Subject: Re: Codezero v0.2 Capabilities
Date: Sun, 13 Dec 2009 13:48:00 +0200
User-agent: Thunderbird (X11/20090817)

Michal Suchanek wrote:
2009/12/7 Bahadir Balban <address@hidden>:
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.



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]