Re: Reviewing Hurd-on-L4 (and considering its future?)

[Paul Boddie]

On Friday 25. May 2018 10.51.48 Richard Braun wrote:
> 
> I don't think the problems we've experienced with Mach would translate to
> an L4 based port, because they were really related to the kernel interface,
> which most L4 implementations don't even provide, such as object
> capabilities (I think OKL4 is the only one to do this) and high level
> virtual memory operations such as paging for anonymous memory.
> 
> On a side note, I personally consider object capabilities a strong
> requirement for a Hurd-like system.

Doesn't Fiasco.OC provide sufficient object capability support, or is the "OC" 
labelling not accurate according to certain criteria? (I can envisage people 
having differing ideas about capability systems.)

"Object-oriented capability system - Unified universal mechanism for naming, 
authorization and communication control"

http://l4re.org/fiasco/features.html

Going a bit deeper...

"Fiasco.OC kernel services are implemented in kernel objects. Tasks hold 
references to kernel objects in their respective "object space", which is a 
kernel-protected table. These references are called capabilities. Fiasco 
system calls are function invocations on kernel objects through the 
corresponding capabilities."

http://l4re.org/doc/l4re_intro.html#fiasco_intro

"As a matter of fact, a system designed solely based on capabilities, uses so-
called 'local names', because each task can only access those objects made 
available to this task. Other objects are not visible to and accessible by the 
task."

http://l4re.org/doc/l4re_concepts_naming.html

From a practical perspective, and from my limited experience writing simple 
servers and configuring them, one uses the init program (Ned) to define 
capabilities and to assign them to programs. It shouldn't be possible to fake 
capabilities due to the design of the system.

How capabilities are transferred and shared is another matter, and I suppose 
that this is where the real design effort begins.

Paul