Single address space

1
Single address space

• Katrin Lang
• user.cs.tu-berlin.de/langk

2
Structuring

• Private address space operating systems (PASOS)
• a critical look
• Single address space operating systems (SASOS)
• a novel approach
• Mungi - implemention, protection model and
  performance
• Related work

3
Advantages
PASOS

• available address space is maximized
• protection is provided by isolating processes

1 / 34
4
Pointers and Sharing
PASOS gt drawbacks

• pointers loose their meaning beyond address
  spaces
• sharing is difficult and expensive
• type information is lost

2 / 34
5
Pointers and Persistence
PASOS gt drawbacks

• record node
• int data
• node next
• record node_saved
• int number
• int data
• int number_of_next

3 / 34
6
IPC
PASOS gt drawbacks
P2
P1
copy
address spaces
4 / 34
7
IPC
PASOS gt drawbacks
applications
OS components
privileged
unprivileged
kernel address space
Cheap, unptotected interaction
Expensive, protected interaction
5 / 34
8
Modularity
PASOS gt drawbacks
applications
OS components
privileged
unprivileged
kernel address space
6 / 34
9
Modularity
PASOS gt drawbacks
applications
privileged
unprivileged
kernel address space
6 / 34
10
Concepts
SASOS

• all processes share one big virtual address space
• addresses have a unique interpretation
• orthogonal persistence
• everything is addressable

7 / 34
11
Protection
SASOS
access rights
protection domain
threads
8 / 34
12
Protection
SASOS
9 / 34
13
Protection
SASOS
9 / 34
14
Design Consequences
SASOS

• no MMU
• no file system
• hardware mapped into memory
• one big page table

10 / 34
15
64-bit Processors
SASOS

• 16 billion gigabyte of data addressable
• local, secondary and remote storage can be
  incorporated

11 / 34
16
Mungi

• University of New South Wales, Australia
• no special hardware
• prototype on the MIPS R4600
• built on top of the L4 microkernel

12 / 34
17
The L4 Microkernel
Mungi gt implementation

• small size
• flexibility
• efficient process management and IPC

13 / 34
18
The Mungi Layer
Mungi gt implementation

• user-level server
• enforces the Mungi protection and addressing
  model
• makes use of message-passing IPC
• protection domains correspond to L4 address
  spaces
• threads correspond to L4 threads

14 / 34
19
Objects
Mungi gt protection

• basic storage abstraction
• basic unit of protection
• range of contiguous pages
• no structure imposed

object
page table
15 / 34
20
Capabilities
Mungi gt protection

• password capabilities
• sparse capabilities
• can be passed around freely
• define access rights for whole objects

64 bit address
64 bit password
16 / 34
21
Access Rights
Mungi gt protection
drwx

• holder may derive weaker capabilities
• owner capabilities allow
• registering new capabilities
• deregistering passwords
• there can be more than one owner

rwx
rw
x
r
17 / 34
22
Object table
Mungi gt protection gt data structures

• one entry for each object
• has to be protected
• is distributed
• distribution is transparent

start address
limit address
rights
password
rights
password
. . .
. . .
rights
password
18 / 34
23
Capability Tree
Mungi gt protection gt data structures
19 / 34
24
Capability Tree
Mungi gt protection gt data structures
pnode
19 / 34
25
Capability Tree
Mungi gt protection gt data structures
clist
pnode
19 / 34
26
Capability Tree
Mungi gt protection gt data structures
h
clist
h
pnode
19 / 34
27
Capability Tree
Mungi gt protection gt data structures
RPD
h
clist
h
pnode
19 / 34
28
Active Protection Domain
Mungi gt protection gt data structures
RPD
h
APD
clist
h
pnode
20 / 34
29
Active Protection Domain
Mungi gt protection gt data structures
RPD
h
APD
clist
h
pnode
20 / 34
30
Access Validation
Mungi gt protection
active protection domain
object table
thread
start address
capability
capability
limit address
rights
password
capability
rights
password
capability
. . .
. . .
password
rights
21 / 34
31
Protection Domain Extension
Mungi gt protection
client protection domain
pdx object
22 / 34
32
Protection Domain Extension
Mungi gt protection
protection domain passed to pdx call
client protection domain
pdx object
22 / 34
33
Protection Domain Extension
Mungi gt protection
protection domain during pdx call
client protection domain
pdx object
22 / 34
34
Protection Domain Extension
Mungi gt protection
client protection domain
pdx object
22 / 34
35
Address Reuse
Mungi

• new passwords assigned at reallocation time
• dangling references present no problem
• new objects entered in kill list
• system call makes objects persistent
• garbage collection impossible
• bank account

23 / 34
36
Posix Conformity
Mungi

• file system can be built on top
• interface to virtual addresses
• chmod()
• changes in capability tree structure
• main problem fork()
• code, private data and stack copied to a
  different memory location
• fork() exec() sequence corresponds to
  TaskCreate()

24 / 34
37
Performance
Mungi
ms
26 / 34
38
Performance
Mungi
34,163
ms
26 / 34
39
Performance
Mungi
ms
26 / 34
40
Performance
Mungi

ms
26 / 34
41
Related Work

• Angel
• runs on standard hardware
• POSIX support
• good performance
• distributed
• no explicit protection system
• built on 32 bit architecture

28 / 34
42
Related Work

• As 400
• Special hardware
• Monads
• Transparent distribution
• No memory reuse
• Restrictions on the use of capabilities
• Special hardware

29 / 34
43
Related Work

• Opal
• No special hardware
• Explicit presentation of capabilities
• Not as pure (shared memory)
• Poor Performance
• JX
• Requires all applications to be written in a
  type-safe language
• Poor performance

30 / 34
44
Conclusion

• SASOS concept is viable
• Can be implemented efficiently
• Performance advantages on certain classes of
  problems
• Simplified OS design
• Applications can be ported without modifications
• No special hardware required
• POSIX conformity

31 / 34
45
References

• Gernot Heiser, Kevin Elphinstone, Jerry
  Vochteloo, Stephen Russell and Jochen Liedtke The
  Mungi single-address-space operating
  systemSoftware Practice and Experience, 28(9),
  901928, (July, 1998)
• Jerry Vochteloo, Stephen Russell and Gernot
  HeiserCapability-based protection in the Mungi
  operating systemProceedings of the 3rd IEEE
  International Workshop on Object Orientation in
  Operating Systems, Asheville, NC, USA, December,
  1993
• Gernot Heiser, Kevin Elphinstone, Stephen Russell
  and Graham R. HellestrandA distributed single
  address space system supporting
  persistenceTechnical Report UNSW-CSE-TR-9302,
  University of NSW, March, 1993

32 / 34
46
References

• Gernot Heiser, Kevin Elphinstone, Jerry
  Vochteloo, Stephen Russell and Jochen Liedtke
  Implementation and performance of the Mungi
  single-address-space operating system Technical
  Report UNSW-CSE-TR-9704, University of NSW, June,
  1997
• Gernot Heiser, Fondy Lam and Stephen
  RussellResource management in the Mungi
  single-address-space operating system Technical
  Report UNSW-CSE-TR-9705, University of NSW,
  August, 1997
• Gernot Heiser, Jerry Vochteloo, Kevin Elphinstone
  and Stephen Russell The Mungi kernel API/Release
  1.0 Technical Report UNSW-CSE-TR-9701, School of
  Computer Science and Engineering, March, 1997
• www.mungi.org

33 / 34