[eros-arch] Re: [CapROS-devel] Problem with the semantics of address
translation and keeper invocation
digitale at digitaleric.net
Fri Sep 2 22:53:51 EDT 2005
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
More information about the eros-arch