Merging sigma0 and roottask

[Alexander Warg]

On Thu, 2013-03-14 at 23:17 +0100, Norman Feske wrote:
> Hello Fiasco.OC developers,

I skip the whole first part of the mail, may be we can discuss this
later...

> Current state and open questions
> --------------------------------
> 
> With the current state of the implementation, the complete software
> stack of Genode runs without sigma0. This includes L4Linux. So I am
> pretty confident that the removal of sigma0 from the system does not
> imply functional disadvantages.
> 
> That said, there are a few remaining questions that I'd like to discuss.
> 
> First, the sole use of 'l4_task_unmap' to remotely flush memory mappings
> in other processes means that we must no longer provide the option of
> granting memory mappings. Otherwise, a process that received a mapping
> from roottask could "steal" the physical memory by granting it to
> someone else. Roottask would not know about that, and an attempt to
> flush the mappings in the original receiver of the mapping would just
> target a hole in the address space. My question is:
> 
>   "Can we live without granting memory?"
> 
>   or the other way: "What is a known use case for granting memory?"

Yes, it is possible to live without grant for memory, however this would
make it impossible to implement a pass-through pager that does not keep
mappings on its own. And second, grant does not allow steeling
something, if Task A wants to revoke memory it mapped to Task B it can
always use its local address to do that regardless of what Task B did by
granting or mapping memory somewhere else.  So in other words the
'l4_task_unmap' call is useful for tasks that are fully controlled by
some other task (tasks that cannot map/grant by themselves) As for
example L4Linux user-level tasks or virtual machines.

So there is no functional benefit from removing 'grant', but there are
legitimate use-cases that are impossible without grant.


> 
> Second, the new situation triggers some code paths in the kernel that
> were not used before. Apparently, the unmapping of memory from sigma0
> was not considered. This is where I hit a few assertions in the kernel.
> Right now, I have just worked around these assertions by uncommenting
> the offending code in 'kernel/fiasco/src/kern/map_util.cpp'. I
> understand that this is just a stop-gap solution. Would you like to lend
> a helping hand to find out...
> 
>   "How to support unmap from sigma0 in a clean way?"

So we currently do not consider removing sigma0 as a user-level process.
Nor do we consider changing the semantics that sigma0 has access to all
physical memory resources. Hence there is currently no good reason to
support unmapping memory from sigma0 because it could regain access to
that memory by accessing it.

Modifying the Fiasco interface in the proposed way would make the
semantics for the sigma0 task very special and to all other tasks on
Fiasco, which is currently not the case.

> 
> I would like to avoid Genode from diverging too much from the semantics
> of the official Fiasco.OC kernel. Hence, I would appreciate your
> consideration:
> 
>   "Would you like to follow a similar path with L4Re?"
> 
> That would be very nice. But even if this should not be the case, I
> would find your rationale behind sticking with sigma0 very valuable to
> know, e.g., for reconsidering my plan.

Currently not, we consider sigma0 being part of our architecture and
will probably stay with it. However, there could be possible
enhancements to the sigma0 interface that support your use-cases. And
there could also be some kernel-interface enhancements that allow more
effective and robust user-level memory management.

regards

-- 
Alex