headers
Bahadir Balban | 7 Dec 14:01
Favicon

Codezero Microkernel v0.2 Released

I would like to announce that Codezero Microkernel v0.2 has been released.

On this release, the microkernel is now fully capability checked, and we
introduced the notion of containers to provide isolated execution
environments. Please see below for a brief description.

1.) Containers

In Codezero containers provide the architectural infrastructure for
isolation of execution environments. Each container is allocated with a
set of address spaces, threads, and any other resource that would
otherwise be globally available on the platform, such as virtual and
physical memory.

Using the simple notion of containers, it is possible to build any type
of software design hierarchy. A hierarchical client/server design, or
multi-threaded standalone applications are both possible scenarios.

2.) Capabilities

Capabilities protect all resources maintained by the kernel. Currently,
all system calls are protected by capabilities, except a few trivial
ones that have been left out. Physical and virtual memory, typed memory
pools, and inter-process communication are among other resources that
are protected by capability checking.

Capabilities build upon the foundation of containers, providing a
fine-grained security architecture, inside and among container boundaries.

We also introduced a capability control system call, by which the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bahadir Balban | 7 Dec 13:59
Favicon

Codezero v0.2 Capabilities

Hi All,

I would like to share with you the current status of Codezero
development as we make the 0.2 release. I am looking into feedback on
various design issues, particularly on capabilities.

I think I have understood Hurd requirements to a good extent, and
Codezero has different final goals compared to the ideal kernel that
Hurd needs.

That said, Codezero has a lot of common grounds with Hurd kernel
requirements, and I would like to focus discussion on these common areas.

What I need is your opinion on our existing capability design, in any
aspect. Security, usability, applicability ... We have implemented
capabilities in Codezero to a good extent, and the design requires
feedback (details to follow on my next email).

What this will bring back to you is that you have the chance to see a
live kernel that has a capability implementation with resources reduced
to a useful small set (e.g. kernel resources), and one that is
attempting to apply it to real practice. You will see your feedback
being implemented in short periods of time, and have the opportunity to
see how it behaves in real. Potentially the same work can be extended,
or copied over to your _desired_ Hurd kernel later on. Think of it as a
small pilot project for your future capability-based Hurd kernel.

If you believe that you already have explored capability-based design to
the extent that you don't need to see any further experimentation, well,
you might just be interested to help.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tom Bachmann | 7 Dec 15:23
Picon
Gravatar

Re: Codezero v0.2 Capabilities


> - The user API has been purposefully simplified, i.e. the capabilities
> are hidden as much as possible from the userspace. The average
> programmer need to know as little as possible about capability design.
> For example you don't pass a capid to a system call. You pass resource
> ids directly, but they get cap-checked internally. Once you want to
> manipulate resource allocation in the system, you then need to
> manipulate (unavoidably) capabilities and need to know what's going
> on at that level.
>  

I don't think that is really useful. Exposing protected capabilities is 
about the *only* thing a microkernel should do (imho. it also has to do 
some resource management but this should be exposed by capabilities as 
well). Moreover, there is no need to try to write a user interface to 
the kernel for "average programmers" because any decent system will wrap 
kernel calls in some fashion or another anyway.

Furthermore, if you actually *can* design the user interface with these 
reasions in mind something very strange is going on. I wouldn't claim to 
be an expert, but both from my own experience and from what I have read 
coming up with *any* kernel interface that works (i.e. that both can be 
used to do what you want and can be implemented efficiently) is such a 
daunting task that "usability" (as in, "for average programmers") is 
really one of the first things you will push to userspace.

Thanks,
Tom
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bahadir Balban | 7 Dec 18:59
Favicon

Re: Codezero v0.2 Capabilities

Tom Bachmann wrote:
>> - The user API has been purposefully simplified, i.e. the capabilities
>> are hidden as much as possible from the userspace. The average
>> programmer need to know as little as possible about capability design.
>> For example you don't pass a capid to a system call. You pass resource
>> ids directly, but they get cap-checked internally. Once you want to
>> manipulate resource allocation in the system, you then need to
>> manipulate (unavoidably) capabilities and need to know what's going
>> on at that level.
>>  
> 
> I don't think that is really useful. Exposing protected capabilities is 
> about the *only* thing a microkernel should do (imho. it also has to do 
> some resource management but this should be exposed by capabilities as 
> well). Moreover, there is no need to try to write a user interface to 
> the kernel for "average programmers" because any decent system will wrap 
> kernel calls in some fashion or another anyway.
> 
> Furthermore, if you actually *can* design the user interface with these 
> reasions in mind something very strange is going on. I wouldn't claim to 
> be an expert, but both from my own experience and from what I have read 
> coming up with *any* kernel interface that works (i.e. that both can be 
> used to do what you want and can be implemented efficiently) is such a 
> daunting task that "usability" (as in, "for average programmers") is 
> really one of the first things you will push to userspace.
> 
> Thanks,
> Tom

This is an impression that I expected. It is not like the kernel has a
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tom Bachmann | 7 Dec 21:09
Picon
Gravatar

Re: Codezero v0.2 Capabilities


Bahadir Balban wrote:
> When it comes to making the ipc call though, you don't pass the 
> capability id to the call. You pass the thread id you want to ipc to. 
> The system call signature is the same as if capabilities were not there 
> at all. But it surely gets checked, the relevant capability is found, 
> it's resource id is matched with the passed thread id, and resolved.
> 

How does capability transfer work in your system? As far as I know, one 
important feature of capabilities is that they unify authorization and 
designation.

Moreover, this breaks (at the kernel boundary!) one important design 
principle (which I value): explicit designation of authority. How can 
your system avoid the confused deputy problem?

> The reason I did it this way is that, when I wanted to do ipc, it feels 
> natural to pass the thread id. You might argue that the capability id 
> could have been the same as the thread id, well in this way I managed to 
> differentiate concepts from each other, and it felt that a user of the 
> interface also benefits by not having to know about capabilities at all 
> (provided that they're initially configured correctly of course).
> 
> 

I also think this is the more natural thing. But see my above comment on 
why I think it is the wrong *fundamental* abstraction.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Sam Mason | 8 Dec 12:15
Picon

Re: Codezero v0.2 Capabilities

On Mon, Dec 07, 2009 at 09:09:50PM +0100, Tom Bachmann wrote:
> Bahadir Balban wrote:
> >When it comes to making the ipc call though, you don't pass the 
> >capability id to the call. You pass the thread id you want to ipc to. 
> >The system call signature is the same as if capabilities were not there 
> >at all. But it surely gets checked, the relevant capability is found, 
> >it's resource id is matched with the passed thread id, and resolved.
> 
> Moreover, this breaks (at the kernel boundary!) one important design 
> principle (which I value): explicit designation of authority. How can 
> your system avoid the confused deputy problem?

Yup, this looks very much like you've just turned what could be a nice
capability system into one that implicitly relies completely on ambient
authority---namely the "capids" that a thread holds.  This is finer
grain than the userid of a conventional process, but still feels like
ambient authority to me.

--

-- 
  Sam  http://samason.me.uk/
Permalink | Reply | 3 comments |
headers
Bahadir Balban | 8 Dec 13:08
Favicon

Re: Codezero v0.2 Capabilities

Sam Mason wrote:
> On Mon, Dec 07, 2009 at 09:09:50PM +0100, Tom Bachmann wrote:
>> Bahadir Balban wrote:
>>> When it comes to making the ipc call though, you don't pass the 
>>> capability id to the call. You pass the thread id you want to ipc to. 
>>> The system call signature is the same as if capabilities were not there 
>>> at all. But it surely gets checked, the relevant capability is found, 
>>> it's resource id is matched with the passed thread id, and resolved.
>> Moreover, this breaks (at the kernel boundary!) one important design 
>> principle (which I value): explicit designation of authority. How can 
>> your system avoid the confused deputy problem?
> 
> Yup, this looks very much like you've just turned what could be a nice
> capability system into one that implicitly relies completely on ambient
> authority---namely the "capids" that a thread holds.  This is finer
> grain than the userid of a conventional process, but still feels like
> ambient authority to me.
> 

The natural signature for operations are retained at the API level, but 
designation and permissions are kept together internally. If you want to 
do operation X, that operation X is very well described by a single 
capability in your capability list. The owner of capability for X can do 
the operation X, with so and so micro-permission allowances, and 
targeting or using so and so resources. Everything that an operation can 
do, and who can do it, is defined and kept in the capability structure.

It's only that the system expects you to know that you have that 
capability in advance, such that, you don't pass the capability to the 
kernel, you ask for the operation, and the kernel checks whether you
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sam Mason | 8 Dec 17:19
Picon

Re: Codezero v0.2 Capabilities

On Tue, Dec 08, 2009 at 02:08:18PM +0200, Bahadir Balban wrote:
> To your ambient authority argument, wikipedia reads:

> The authority is "ambient" in the sense that it exists in a broadly 
> visible environment (often, but not necessarily a global environment) 
> where any subject can request it by name.
> "
> 
> This is not true for this case, since designation, authorization and 
> ownership information is all bundled in the capability structure and 
> gets checked on each operation.

It depends on the level of abstraction you're thinking about.  Within
codezero a single process can exercise all authority in error because
the kernel checks which capabilities determine whether an operation has
enough authority to proceed.  When the capabilities are directly exposed
to the process it's "harder" for it to go wrong because the code is
directly naming the authority needed for every operation.

Admittedly this is a qualitative appeal rather than a quantitative one,
but I don't possess the experience to argue the point in any other way.

--

-- 
  Sam  http://samason.me.uk/
Permalink | Reply | 1 comment |
headers
Bahadir Balban | 13 Dec 12:48
Favicon

Re: Codezero v0.2 Capabilities

Michal Suchanek wrote:
> 2009/12/7 Bahadir Balban <bahadir <at> l4dev.org>:
>> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bahadir Balban | 13 Dec 13:16
Favicon

Re: Codezero v0.2 Capabilities

Sam Mason wrote:
> On Tue, Dec 08, 2009 at 02:08:18PM +0200, Bahadir Balban wrote:
>> To your ambient authority argument, wikipedia reads:
> 
>> The authority is "ambient" in the sense that it exists in a broadly 
>> visible environment (often, but not necessarily a global environment) 
>> where any subject can request it by name.
>> "
>>
>> This is not true for this case, since designation, authorization and 
>> ownership information is all bundled in the capability structure and 
>> gets checked on each operation.
> 
> It depends on the level of abstraction you're thinking about.  Within
> codezero a single process can exercise all authority in error because
> the kernel checks which capabilities determine whether an operation has
> enough authority to proceed.  When the capabilities are directly exposed
> to the process it's "harder" for it to go wrong because the code is
> directly naming the authority needed for every operation.
> 
> Admittedly this is a qualitative appeal rather than a quantitative one,
> but I don't possess the experience to argue the point in any other way.
> 

I thought that once a process has a certain capability, it doesn't 
matter how it is invoked. It may be explicitly by a capid, or 
implicitly. Keeping the existing L4 interface was highly desirable for 
design reasons so I implemented it this way.

I didn't get how a process would exercise authority in error. If you
(Continue reading)

Permalink | Reply | 0 comments |

Gmane