SAS and mapping descriptors

[Jonathan Shapiro]

Umm.  I think we went down a rathole.  I believe that my comments
about mapping descriptors apply equally to SAS and non-SAS approaches.

   >2. Mapping capabilities are insecure and unreliable.

   That's only true in a _non-SAS_ system - in a SAS system, if you
   have something mapped at address X, then you are positively guaranteed
   that _no one_ has anything else mapped at that address.
   So if you receive a mapping capability, you can just plug it in and use it.
   (There's still the issue of whether you trust the pager that backs those
   mappings, of course, but that's the same in either case.)

This is the place where I think we miscommunicated.  I wasn't really
very concerned about the space being reserved properly -- I agree that
this is a solvable problem.  I was concerned about mapping
capabilities causing things to be implicitly mapped into my address
space without my taking an explicit action to cause the mapping.  

The implicitness is the fundamental insecurity that I perceive.

If you buy in on the problem of implicitness, then the rest of my
argument follows: Once a process has to explicitly accept a mapping,
there isn't much advantage to sending a mapping rather than an object.
On the other hand, I hadn't considered the additional challenge of
structured data.

   >3. Mapping capabilities impose hidden unbounded costs on the
   >recipient. Mapping an object requires system resources (to hold the
   >mapping description) that the receiver may not have sufficient
   >authorization to allocate.

   No, the mapping description is the object pointed to by the mapping
   capability, and therefore it is allocated by the sender (or whoever
   created the mapping capability in the first place).  As long as the
   receiver has a protection domain to plug the mapping capability into
   (if it didn't it wouldn't be running), there's no problem.

The problem lies in allocating space in the receiver's protection
domain.  This may imply the need for the recipient to IMPLICITLY
allocate an unbounded number of page frames in order to construct
mapping sub-tables supporting the new mapping in the recipient's
protection domain (still an issue in a SAS, if the mapping has
different permissions depending on the viewer... note also the
difficulty of accounting if sub-tables are shared).

Performing a mapping has a definite cost on the client.  The fact that
we traditionally do not account for this cost does not mean that it
doesn't exist.

Just to be clear, my objection is once again to the implicitness, not
to the cost.

   In a SAS system, the idea is generally that when you pass around mapping
   capabilities, you're passing around access to _structured_ data that
   can only be interpreted easily if it's mapped at certain addresses -
   in other words, arbitrary data structure graphs containing pointers.

Okay.  I'll admit to a bias here.  I'm interested in heterogeneous
computing clusters, so I'm not very interested in SAS architectures.
I should probably reconsider the issue, as the SAS architectures are
trying to address some entirely legitemate and important issues.

   You're confusing the terminology a little.

Thanks for the correction.  I tried to get the terms right in my
comments above.

   I think you're right about this one - it would be cleaner to implement
   COW as composed memory objects than composed mappings.  In fact, this
   is really the only way to do it right if you allow multiple mappings
   of the same memory object.

I hadn't considered that, and I think you're quite right.


Jonathan