l4-hurd
[Top][All Lists]
Advanced

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

Re: [ANNOUNCE] Introducing Codezero


From: Bahadir Balban
Subject: Re: [ANNOUNCE] Introducing Codezero
Date: Wed, 29 Jul 2009 12:58:49 +0300
User-agent: Thunderbird 2.0.0.22 (X11/20090608)

Bas Wijnen wrote:

While the provided links may certainly help, I think the biggest
"conflict" is that Bahadir seems to be talking about unprotected
capabilities (but correct me if I'm wrong), while most people here
implicitly mean "capability" to be kernel-protected.  What I mean by
protection is that it is impossible (not just very hard) for a thread to
guess a capability, because when invoking, the kernel checks if you
actually have it.

This effect does indeed inflate the kernel, but it also has some good
effects on security, which cannot be achieved without kernel support.

Again, I'm not saying this is something you must aim for with CodeZero.
But it is something that IMO the Hurd should aim for (and I think most
people here agree, but I'm not even sure about that).

Thanks,
Bas


Hi,

If the capability is kernel protected, you have the option of discarding
invocations in the kernel without the invokee knowing about it. In
userspace capabilities the invokee will need to accept the IPC in order
to discard it thus spending cycles for every unsolicited request. Well,
this is one bit where I need to evaluate the tradeoffs. In the first attempt, I am implementing kernel capabilities for kernel-provided resources only.

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.


Thanks,

--
Bahadir Balban





reply via email to

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