Re: Sawmill's dataspaces and the Hurd's physmem

[Neal H. Walfield]

At Mon, 05 Sep 2005 21:59:30 +0200,
Bernhard Pöss wrote:
> The design for a Dataspaces environment would be as follows:
> Simplified you've got:
> - Dataspace Manager providing open / close / map / grant
> - Region Mapper providing attach / detach and pf handling
> - client
> 
> client and region mapper are in the same address space(AS). Think
> of a region a continous area of virtual memory in the clients AS
> that makes a part of a dataspace available to the client.
>                
>   [ dataspace manager ]     
>           |
>   request page for region
>           |
>   [ region mapper | client ]
>           |             |
>           |--<--- PF -<-|
>          
> 
> A page fault scenario would be as follows:
> 1. The client triggers a page fault
> 2. The region mapper (pager of client) receives PF
> 3. The region mapper requests the page from the dataspace manager 
> (possibly with a timeout)
> 4.A The dataspace manager maps/grants the page to the region mapper and 
> thus to the client (same AS)
> 4.B The dataspace manager denies to map the page / timeout fires
> 5. The region mapper is free to act upon the behaviour of the dataspace 
> manager
> 
> An open - attach scenario would be:
> 1. client sends open call to DS manager, receives dataspaceid (DSID)
> 2. client attaches to the region mapper with the DSID
> 3. Now the region mapper is capable of resolving PF in the region the DS 
> is mapped
> 
> I hope I've pointed out where your interpretation was missdirected.

Thanks for the explanation but I don't understand what in your text
you think is inconsistent with my understanding of data spaces.  The
issue that I have noted is that after a DM maps an fpage to a client,
the DM can unmap it at any time.  My claim is that the result is that
the client of the DM must trust the DM to always provide a mapping or
it must make a physical copy of the fpage.

> Besides the general discussion about dataspaces here, isn't your 
> approach very centralized and thus
> a possible bottleneck for the system ?
> One of the ideas behind dataspaces was in fact to decentralize memory 
> management by e.g. stacking
> dataspace managers.

I think it is fair to say that the root of the DS hierarchy is also
centralized.  I've designed the physmem interfaces to provide what I
view as the minimum required mechanisms to maximize sharing and
flexibility, minimize trust and permit accountability.  As I
understand the DS model, I think my approach is better for each of
these four points.  I may, of course, be overlooking something.  This
email thread is specifically about the security issue, however, I'm
interested in discussing if my approach is really minimal and what
alternative approaches there are.

Thanks,
Neal