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