Re: [ANNOUNCE] Introducing Codezero

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