|
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
[Prev in Thread] | Current Thread | [Next in Thread] |