[CSE]  Advanced Operating Systems 
 COMP9242 2002/S2 
UNSW

PRINTER Printer-Friendly Version
Administration               
- Notices
- Course Intro
- Consultations
# On-line Survey (closed)
- Survey Results
 
Work
- Lectures
- Milestone 0
- Project Admin
- Project Spec
- Project FAQ
- Exam
 
Documentation
- ASysT Lab
- L4 source browser
- Sulima ISA Simulator
R4x00 ISA Summary 
MIPS R4700 ReferenceMIPS R4000 User Manual 
- Network Driver
- GT64111
 
Related Info
- Aurema OS Prize
- OS Hall of Fame
 
History
- 2000
- 1999
- 1998
 
Staff
- Gernot Heiser (LiC)

 
Valid HTML 4.0!
next up previous
Next: Password capabilities Up: 03-caps Previous: Partitioned Capabilities

Subsections

Sparse Capabilities

Basic idea similar to encryption:
  • Add bit-string to make valid capabilities a very small subset of the capability space.
  • Can be encrypted object info or something like a password.
  • Capabilities are pure user-level objects, which can be passed around like other data.
  • Appropriate for user-level servers.

Example: Signature capabilities


``First Migration Scheme''[GL79], designed to allow migration of tagged capabilities in distributed systems.

cap-m1
+
tamper proof via encryption with secret kernel key
+
can freely be passed around
-
need to decrypt on each validation
-
users do not know which object capability refers to



  • \(f\): one-way function (secure digest), \(E\): encryption function

``Second Migration Scheme''[GL79]

cap-m2

Object ID visible, yet still tamper proof.

Amoeba's capabilities

cap-a1

Appropriate for user-level servers [MT86].

Properties of Amoeba capabilities


  • Port identifies server.
    • Kernel resolves server and caches server location.
  • Port IDs are large (48-bit) sparse numbers.
    • Knowledge implies send rights.
  • Creator (``owner'') has all rights.
  • Server uses OID to look up rights, checks fields to validate.
    • Validation done by user-level server when invoked.
    • Propagation easy, as capabilities are ``normal'' data.
    • Restriction requires server to make new capability.
    • Revocation done by server removing entry from object table.
      But not very helpful if only one capability per access mode.
    • Amplification possible according to server policies.
    • Accessibility is impossible to determine.
    • Protection domain is impossible to determine.

Amoeba rights restriction

cap-a2

  • Used by server to derive lesser capabilities on request.
  • No need to store derived capability in object table.

Improved version (not implemented)

  • Set of commuting one-way functions \(f_i\), one for each access mode bit:
    \(f_i(f_j(x))) = f_j(f_i(x))\).
  • To remove access mode \(i\), obtain new check field as:
    \(C' = f_i(C)\).
  • Can be done by user without server intervention.

Server authentication: F-boxes

  • Hardware device ``F-box'' at each network connection
    • When requesting messages for port \(G\), F-box will only accept messages destined for port \(P=f(G)\), where \(f\) is a one-way function
    • Server publishes \(P\) as port ID
    • Intruder who does not know \(G\) cannot access messages
  • Scheme depends on physical security of F-boxes (or their implementation in the OS).
  • Never been implemented (to my knowledge).


next up previous
Next: Password capabilities Up: 03-caps Previous: Partitioned Capabilities
Gernot Heiser 2002-08-15