[cap-talk] Language-based safety - MMP - reading
David Hopwood
david.nospam.hopwood at blueyonder.co.uk
Thu Nov 18 23:30:07 EST 2004
Jed at Webstart wrote:
> At 01:37 PM 11/17/2004, Wes Felter wrote:
>> On Nov 15, 2004, at 7:40 PM, Jed Donnelley wrote:
>>
>>> Of course it's an interesting question to ask whether there might be
>>> some instruction set architecture where Bob could still execute
>>> arbitrary code and still be able to execute in the same hardware
>>> domain as Alice. It would seem that whatever mechanism is used for
>>> Java or E should suffice in hardware (I'm guessing here) if that were
>>> practical, so I guess the theoretical answer is "yes", but there may
>>> be some distance between the theoretical and the practical.
>>
>> Consider Mondriaan memory protection:
>> http://www.cs.utexas.edu/users/witchel/
>
> I'm started down that investigative path, but haven't found anything yet
> to suggest that MMP would make the ability to execute arbitrary code
> possible within a process that includes separate protection domains in
> separate modules.
I've only skimmed the papers, but it seems to me that MMP is a fairly
straightforward segmented memory architecture with word-granularity
segments. There have been several previous capability system designs
based partly on segmentation; in principle, it's possible to implement
a cap system using *only* segmentation. Implemented systems tended to
be more complicated, but the nearest thing to a segmentation-only
design I can find a reference to right now is the Chicago Magic Number
Machine (http://www.cs.washington.edu/homes/levy/capabook/Chapter3.pdf).
Is it that you don't see how those systems (would have) enforced the
capability model, or is it something specific to MMP?
In particular, "within a process" seems to be irrelevant in MMP, since
process-level mechanisms are not what is being used to separate domains;
the segment permissions are per-protection domain, not per-process.
It's not critical what the mapping between processes and protection
domains is.
--
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the cap-talk
mailing list