Merging sigma0 and roottask

[Alexander Warg]

On Tue, 2013-03-19 at 09:34 +0100, Christian Helmuth wrote:
> Hello Alex,
> 
> thanks for your reply, but as you might have expected there are some
> follow-up questions...
> 
> On Mon, Mar 18, 2013 at 05:19:08PM +0100, Alexander Warg wrote:
> > 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.
> 
> Is the pass-through pager really a use case or more like a theoretical
> construct. I was always wondering what the scenario would look like
> that needs this kind of pager. Could you please elaborate more on
> this?

If this example is too theoretical, and yes we currently have no such
construct in use. There is a different use case that is facilitated by
grant which is a local move operation e.g. for an mremap-like operation.
Where a local region mapper can use grant to move mappings to a
different virtual address.


> 
> > 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.
> 
> Hm, I'm not that familiar with the current mapping interface/rights,
> but does that mean there exists a feature to prevent mappees from
> further delegating page-frame access rights via map or grant?

No, at least not directly. However you can prevent threads in an address
space to do a system call at all (either using VCPU features or the
'alien' flag).

> 
> > 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 doubt that Norman's proposal does change that much "semantics"
> regarding Sigma0 as it's special anyway and can map any physical frame
> into its address space by just touching the corresponding address.
> Please consider, that the proposed changes could lead to a noticable
> gain in robustness for the most-privileged user-level process on
> Fiasco.

sigma0 is not really special, from user-level perspective it just has a
pager that resolves its page faults transparently.

> 
> > 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.
> 
> Do you already have some ideas to discuss here? I'd highly appreciate
> a lively dicussion on this (at least for us) important topic.

The ideas are currently not in a shape that I want to discuss them here.

regards

-- 
Alex