[cap-talk] Another "core" principle - virtualizing memory

[Jed Donnelley]

At 09:43 PM 1/16/2007, Charles Landau wrote:
>At 3:48 AM -0500 12/29/06, Jonathan S. Shapiro wrote:
> >I can already here Charlie Landau warming up his keyboard
>
>Well, now I feel obligated to respond, even though I'm hopelessly
>behind on the discussion, and the major points have been addressed by
>others.
>
>At 2:25 PM -0500 12/31/06, Jonathan S. Shapiro wrote:
> >If we restrict ourselves to capabilities implemented by processes
> >(presumably stretching to include the kernel as a distinguished
> >process), we cannot account for address spaces, memory mapping, or
> >shared memory within the protection model of the system. That seems
> >disastrously bad.
>
>Yet you yourself said:
>At 3:27 AM -0500 12/29/06, Jonathan S. Shapiro wrote:
> >The "traverse" right is conceptually equivalent to having a service S
> >that implements two facets A and B, will directly disclose some
> >capability to A, but will only wield it indirectly for B. The only
> >difference is that by reifying this right in the operational semantics
> >it becomes possible to do information flow analysis without analyzing
> >the code of S. We haven't exited the capability model at all here. It is
> >merely an optimization.
>
>So, considering the kernel as a distinguished process, isn't the
>protection model intact?
>
>In more detail: the kernel implements both processes and memory
>objects. As part of implementing (i.e. simulating) a process, the
>kernel implements memory accesses. To implement a memory access, the
>kernel examines the address space capability. Assuming it is a memory
>object, MyCap can identify it, because memory objects are also
>implemented by the kernel. Thus the kernel can access the internals
>of the memory object to traverse the tree and obtain the data in the
>page. In this description, there are no mapping tables.
>
>The kernel cleverly makes use of the CPU and MMU and mapping tables
>to do all this efficiently, but that is no concern of the model,
>given that the necessary storage allocations, such as page tables,
>can be tied to objects such as nodes.

Nicely stated.

> >For most
> >purposes, the DSM-like approach that you (and Charlie Landau) advocate
> >will turn out to be fine for virtualization at the desired level of
> >abstraction, and it's a perfectly fine solution. I have merely been
> >noting that this approach does not constitute virtualization at the
> >level of individual capability invocations (i.e. loads and stores), and
> >as such it is not the same type of virtualization (qualitatively) as
> >front-ending an entry capability is. Finally, I noted that actually
> >doing virtualization at that level is technically possible, damned hard,
> >and is probably not useful for any purpose other than debugging.
>
>I agree. The kernel cannot efficiently "virtualize" memory objects at
>the level of individual loads and stores ("virtualize" in the sense
>of, implementing semantics beyond that supported by the MMU) so it's
>not surprising that users can't either.

I'd pretty much given up on this thread, but the above fits exactly with
my thinking, with perhaps a bit more of a KeyKOS perspective and
more virtual memory experience/terminology.   Thanks Charlie.

--Jed http://www.webstart.com/jed/