Merging sigma0 and roottask

[Norman Feske]

Thanks Alex for your response,

> 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.

I am afraid that I did not express the fundamental idea of my proposal
well enough. In the new version of roottask, roottask maps directly from
the physical address space to the virtual address space of all other
processes (in your example, this is task B) without keeping a local
mapping. So roottask does not possess a mapping node to revoke such
mappings. In order to be able to revoke mappings, it keeps records of
the virtual addresses to where it installed the mappings in the other
tasks. For revoking a mapping, roottask performs 'l4_task_unmap' with
the remote task capability and the remote virtual address range as
arguments.

The "stealing" would happen if task B grants the mapping to somewhere
else. My incentive behind the removal of the memory-granting mechanism
is solely to avoid this loophole. I would appreciate to know more
specifically, which "legitimate use cases" this would break. For
example, does L4Re relies on granting memory?

Please note that the mapping database is still in effect for mappings
further propagated by task B. But task B would be the root of the
mapping tree.

> 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.

I did not suggest at all to change sigma0/roottasks's ultimate power
over physical memory. Sigma0/roottask can still map any physical page to
its local address space using l4_task_map with the physical address as
source and its local virtual address as destination. The two fundamental
differences are that those mappings are not installed auto-magically but
explicitly, and that the mappings are not necessarily identity mappings.
By explicitly installing the mappings, roottask gains robustness. By
removing the identity-mapping policy of sigma0, roottask can use its
virtual memory more flexible.

My line of thinking is that the fewer memory is shared between roottask
and other user-space processes, the better. The current architecture
shares all memory of all processes with roottask. In the variant I
suggest, roottask shares no memory with other user processes.

> 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.

Even though sigma0 and roottask happen to be executed in user space,
both are logically part of the operating system's kernel because all
other processes ultimately depend on them. According to the principles
of microkernel construction, the kernel should be free from policy. Yet,
you support keeping policy in the form of sigma0, which can easily be
removed as my experiment suggests. According to the minimality
principle, the kernel should contain functionalities only if they are
strictly needed. I fail to grasp how sigma0 qualifies for that. When
looking at the problem from this perspective, "enhancing" the sigma0
interface looks like going in the wrong direction. It would make the
kernel of the system (which is not merely the code executed in
privileged mode) not less complex but more complex.

>From your mail, I understand that you do not feel any urge to change the
status quo as sigma0 apparently causes no problems for you. Even though
I was hoping for a different response, thank you for stating your stance.

Regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth