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

[Charles Landau]

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.

>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.