School of Computer Science & Engineering
University of New South Wales
Advanced Operating Systems
COMP9242 2002/S2
next
up
previous
Next: Sparse Capabilities
Up: 03-caps
Previous: Tagged Capabilities
Subsections
- System maintains capability list (clist) with each process (in PCB).
- User code uses indirect references to capabilities (clist index).
- System validates access via clist when mapping any page.
- Validation is implicit at page fault or explicit mapping time.
- Propagation: system intervention to copy between clists.
- Restriction: kernel to make new capability.
- Revocation: kernel to remove cap from all (or specific) clists.
- Accessibility can only be determined by scanning all clists.
- Protection domain is explicitly represented in clist.
- Hydra[CJ75], Mach[RTY$^+88ドル],
KeyKOS[BFF$^+92ドル], Grasshopper[DdBF$^+94ドル],
Eros[SSF99] and many others.
- Capabilities can be propagated via IPC.
- User must insert capabilities (clist indices) into special field
in message.
- Kernel looks up clists and inserts representation of ``real''
capability (marshaling).
- Receiver's kernel inserts capabilities into receiver's clist.
- Kernel replaces capability in message by clist index.
- Can be simplified if IPC is local.
- Amplification can be performed by schemes similar to AS/400.
- Secure through kernel protection.
- Validation at mapping time
==>
apps use ``normal'' pointers.
- Fast validation (clist check is simple, validation cached
by MMU).
- Propagation requires marshaling and kernel intervention.
- Reference counting possible to detect unaccessible objects.
next
up
previous
Next: Sparse Capabilities
Up: 03-caps
Previous: Tagged Capabilities
Gernot Heiser
2002年08月15日
[an error occurred while processing this directive]