Re: Multiaddress space message passing virtual machine
Posted: Wed Jul 24, 2013 1:46 pm
An intesrting concept for a single address spaced virtual machine would be the use of domains used in Mungi.
after all this I think it would be better to just emulate the hardware to a degree and use host integration like HostFS and passthrough daemons.
after all this I think it would be better to just emulate the hardware to a degree and use host integration like HostFS and passthrough daemons.
Still a cool idea4.1 Protection Philosophy
One of the most obvious advantages that single-address-space systems have over separate
address space system is the ease with which sharing can be accomplished. Consequently,
the design of a protection mechanisms needs to take great care that sharing is not unduly
hindered; conversely we cannot ignore protection as this would render the resultant system
unsuitable for use in a multiuser environment.
Ideally a protection mechanism should be unobtrusive, o er perfect safety, allow the
implementation of arbitrary security policies and have no performance impact on the system.
It is obvious that this is an impossible goal. In reality the aims are: a protection system
that is exible, intuitive and has as little performance impact on the user as possible. These
requirements form a subset of the Mungi design requirements; in particular the following
32CHAPTER 4. PROTECTION IN MUNGI
33
subset provided the guiding principles for the design of the Mungi protection system.
Flexibility: The protection mechanism should not limit the security policies that can
be implemented using Mungi primitives. A limited range of security policies restricts
the use of the operating system to a speci c range of of environments.
Simplicity: Protection can only be applied to entities that can be named. In the
Mungi single address space there is only one name for each entity, its virtual address.
This allows Mungi to implement protection simply by applying the \3 R's" (read,
write and run).
Ease of use: Good protection mechanisms don't necessarily translate to good security.
If protection is too invasive or counter-intuitive users will not routinely apply it.
Therefore, operating system primitives should allow the intuitive application of good
security practice. Further, while a na ve user should not need to understand the
protection mechanism to apply good security practice, the security conscious user,
who does understand the protection mechanism, should be able to arbitrarily enact
any security policy that they wish.
Performance: The need to minimise the performance impact is obvious. Protection is
not tolerated if the costs are prohibitive.