Re: [ANNOUNCE] Introducing Codezero

[Bas Wijnen]

On Wed, Jul 29, 2009 at 12:58:49PM +0300, Bahadir Balban wrote:
> If the capability is kernel protected, you have the option of discarding
> invocations in the kernel without the invokee knowing about it.

You can call it an option; I would call it a requirement. ;-)  One of
the main features of the protection is that the server cannot know when
an unauthorized client is trying to connect.

> In userspace capabilities the invokee will need to accept the IPC in
> order to discard it thus spending cycles for every unsolicited
> request.

That is indeed an additional issue, which is performance-related.  It is
of course a matter of taste, but I think that security is almost always
more important than performance.  If you succeed in building an insecure
system, then I can just as well use Linux.  Perhaps there are some toy
features to a microkernel design, but without real security it doesn't
have the main selling point that cannot be implemented (realistically)
in a monolithical kernel.  But that's just my preference, and if people
are happy with less security (and many people are!), then they can of
course go for performance at the cost of the security they didn't
experience before anyway. :-)

> Well, this is one bit where I need to evaluate the tradeoffs.

It certainly is a policy choice.  There is no "best" approach (except if
full security happens to coincide with maximum performance, but it
doesn't: maximum performance will always be to put everything, both
kernel and user space, into a single address space).

> In the first  attempt, I am implementing kernel capabilities for
> kernel-provided  resources only.

That means every resource-provider must protect its own resources. ;-)

> The other issue is how the remote service (or resource) is represented.
> In my system requests are represented merely by request numbers as
> opposed to object references. So my argument is to remove the
> "everything is an object" assumption but just use the capability part to
> protect resources.

I don't really understand what you're saying here.  I have the feeling I
don't really understand what you mean by "object".  Can you give some
examples of what is an object-based approach, and what is an approach
without objects?

On Wed, Jul 29, 2009 at 12:57:28PM +0300, Bahadir Balban wrote:
> Sam Mason wrote:
>> archives and the following looks like a nice early reference:
>
> For example this is a very generic example of how the protocols may get
> fairly complicated. The details are unimportant; it is chosen from your
> reference pretty randomly:

This example is from the attempt to create a capability system on top of
L4 pistachio.  In particular, it is about how to implement a capability
copy, where L4 only provides map and grant operations.  The result is a
protocol to tell a common parent to map something that A owns.  I agree
that this is very complicated.  This, plus other problems with
implementing the capability system, was a reason for us to abandon L4 as
a future kernel.  Something like Eros or Coyotos looked more appropriate
(that has been influenced a lot by Jonathan Shapiro advertising for them
on this list ;-) ).  At the moment, I think there is a general agreement
that we need a microkernel with kernel-protected capabilities, with at
least a built-in copy operation.

> There are handles, references being passed, transaction ids, etc. This
> won't work. The protocol will get extremely complicated, and you give an
> opportunity to monolithic kernel people to despise your design.

Of course if it's only complex, there isn't really a problem; it can be
put in a library and nobody needs to see it.  The problem is that
complex usually also means slow.  It certainly does here.  The
performance penalty that this approach gave was unacceptable.

> Things should be kept very minimalistic. You should always keep in mind
> that you are competing against mere function calls in a monolithic kernel.

Personally, I don't think performance should be the selling point of a
microkernel design.  Even if it may be possible to be slightly faster than
monolithical designs, the difference will never be large enough to
convince people to switch.  Also, for the developers, I don't think
performance is the reason they're working on it.  At least I am working
on my kernels because they put the computer back into the hands of the
user (instead of the programmer and system administrator, as it is now).
If that is possible without losing too much performance, I'm happy.

> Monolithic people say it gets very complicated to debug the
> communication.

They do?  I find it is much easier because the communication is so much
better defined.

> I very rarely ran into such problems. I am confidently speaking about
> it because I have done this to a certain extent. A design such as
> above, together with synchronous communication feels like you are
> developing on a monolithic system.

It is a good example of trying to implement something on a system that
really isn't well-suited for it.  Which means that you must choose to
want something else, or to use a different underlying system.

> But getting back to capabilities, in my understanding a capability is
> just a structure that describes a resource as well as the security
> permissions on it and its owner.

Sam said it pretty well, but I think you may mean the right thing.  A
capability is something that gives access to a resource.  whether or not
you call this resource an object is irrelevant.  When invoking the
capability, the resource is used.  The security part is not inside the
capability, but in the fact that a process holds it.  Only a process
holding a capability can invoke it.  And as Sam said, it is unforgable:
you cannot create a capability and use it.

> It's a compact, elegant description of resource  accessibility that
> can be dynamically passed around. Could it be used as a central
> mechanism to access programmatically created objects? Yes. But it
> doesn't have to be. Using the compact definition I just used, it is
> powerful enough to build all the secure communication that a
> microkernel needs. IOW I am suggesting to drop objects, and use
> capabilities to secure ad-hoc services and resources.

There is a choice about whether or not you want kernel resources to be
managed as objects.  To me, it feels very natural to do this.  But I'm
sure it's possible to do it differently.  However, that is not so
important.  Most of the communication will be between threads.  Threads
send messages to each other with capabilities.  They decide if they want
to use an object-based approach; the kernel isn't involved.

> 1.) Demonstrate kernel capabilities in userspace servers mm0/fs0 (e.g.
> thread, space creation, manipulation, ipc etc.)
>
> 2.) Extend ipc capability mechanism to include ipc request numbers,
> either in userspace or as a kernel extension, so that all ipc-based
> requests can be covered by capabilities. (e.g. Think of IDL as opposed
> to just request numbers to servers, and compare which is more heavy-weight).

Better think several times before extending the ipc mechanism; it's the
most used path in the system.  Any performance hit in that path counts
very many times.

Finally, I'll repeat my request from above, so you don't forget it:
please give some examples of what you mean by objects.  I don't really
understand what it is that you're trying to avoid, so some explanation
would be helpful.

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://a82-93-13-222.adsl.xs4all.nl/e-mail.html

signature.asc
Description: Digital signature