[eros-arch] Re: [CapROS-devel] Problem with the semantics of address translation and keeper invocation

[Eric Northup]

On Fri, 2005-09-02 at 17:29, Charles Landau wrote:
> >I don't recall who proposed this fix (Scott thinks it was Shap), but it
> >does address the problem of the unintended communication channel. We
> >could change the way we define a valid translation path, so that instead
> >of bounding the total number of steps in the path, we bound the number
> >of steps it takes to translate the range of bits matching a hardware
> >page table.  The total path length is still bounded, but in a way that
> >makes it unnecessary to check the length of multiple cached translation
> >paths in response to a single page fault.
> 
> I believe this is the way KeyKOS worked, and it seems like the 
> correct way. Specifically, there need to be separate bounds on each 
> portion (I was going to say each "segment") of the path:
> 
> 1. From the domain root, to the node defining the whole address 
> space, corresponding to CR3 (usually this is of length one, but in 
> KeyKOS it could be more). In KeyKOS, the top-level page table ("page 
> directory" in x86, e.g. PageTable2) could be shared.

I was a bit surprised that EROS does not share the top-level page table.

I don't quite understand the case where the node defining the whole
address space is not directly named by the address space root
capability.  Even if there are several layers of non-translating/wrapper
nodes, doesn't the first wrapper still define the address space?

[...]
> Furthermore, KeyKOS used any existing translations to optimize the 
> tree walk. If a mapping exists from CR3 to a page table, it would 
> begin walking from the node corresponding to the page table, instead 
> of from the domain root. So the tree walk really was broken into 
> three separate tree walks for the three levels.

EROS/CapROS also use existing translations to skip parts of the software
translation (look for FAST_TRAVERSAL in
eros/src/sys/arch/i486/kernel/PageFault.c).

-Eric