SAS and mapping descriptors

[Bryan Ford]

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

I don't see how this causes any security problems.  If I receive
a mapping capability and it happens to contain extraneous sub-mappings
that I don't need to look at, I'll just never access them.
It's known that those mappings can't possibly conflict with any
of the other mappings that I _do_ want to access, so the sender
can't violate my integrity.

If by "insecurity" you're referring to the potential problem of a
sender "accidentally" dropping an extra sub-mapping into a composed
mapping and giving other processes access to memory they shouldn't have,
then basically you're objecting to allowing a process to hang itself -
and that's impossible anyway.  It's just as easy to "accidentally"
pass a wrong memory object capability to someone as it is to "accidentally"
pass a composed mapping capability that has too much privilege.

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

Only enough mapping sub-tables need to be constructed in the receiver
to cover the actual parts of those composed mappings that the receiver
actually attempts to access.  Those resources are simply resources
that the receiver needs in order to execute: exactly the same as the
resources holding the MMU tables for the receiver's code.  Unless the
receiver is coded so naively that it might try to access an "unbounded"
amount of memory (an hence force an "unbounded" amount of mapping resources
to be allocated) before figuring out that something is wrong, there
should be no problem.  In any case, these MMU table resources are generally
implemented as caches anyway, so they can be dynamically thrown away and
reallocated to map other parts or memory.

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

Actually, SAS does not necessarily mean homogeneous.  (And as I've said
before, even if it did, we're not going whole-hog SAS in Mach; we just
want to support it effeciently as an option.)  There are now tools,
some of which were developed here, that allow arbitrary structured
data to be automatically massaged as necessary when pieces of DSM are
transferred across heterogeneous nodes.  So, for example, you could
share a single address space between a big-endian PA-RISC machine and
a little-endian i386.  Sharing between machines with different word sizes
would be more difficult, but still potentially solvable to some extent.

				Bryan