Programming Semantics for Multiprogrammed Computations
Dennis & Van Horn
i. Standard interfaces
ii. Standard extension points
iii. Tree-like/graph like structures because layers are replaceable
i. Not designed as replaceable modules, but as virtual machines
ii. Provides same, but limits to whole system so less flexible
iii. Upper layers may be dependent on implementation details of lower layers; because not replaceable
i. Goal: System to satisfy all needs, and be flexible in future.
i. E.g. ctss:
1. File system – only way to share data
2. Processes launched only from command line
3. Users own files, processes
4. No IPC or sharing
i. Details of sharing segments & linking fairly complex
i. efficient sharing, protection, utilization
i. Segment-based protection
ii. C-list
iii. supervisor
iv. Inferior spheres
v. hierarchical FS
vi. Process / processor
1. Are these the same definitions we use today?
i. FS
1. canŐt rename
2. canŐt truly delete
a. But can – delete makes any reference fail
ii. Deadlock not really discussed
1. QUESTION: what happens today:
iii. Too complex
i. Protection for security – can have lots of users with private documents / code
ii. Sharing for efficiency or deliberately
iii. Parallel programming
iv. Future-proof extensibility
v. QUESTION: Did they do this?
i. What structures/units are needed: e.g. process, computation, segment, etc.
ii. What operations are needed
i. Parallel processing
ii. Naming object of computation so can be referenced/shared
iii. Protection
i. Concurrently run multiple processes from different users
ii. Share resources in flexible way; donŐt plan for fixed resource sizes
iii. Wide variation in computation requirements
1. Statistical multiplex to achieve high utilization
iv. Reference to common information by separate computations common
1. Communication also common
2. QUESTION: is this true? What is the pattern? Read? Write mostly? Append? Update?
v. Must evolve to meet changing requirements
1. E.g. add additional memory, processors, peripherals
i. Note: will compare against Unix
i. Definition: locus of control within an instruction sequence
ii. QUESTION: what is Unix equivalent?
1. A: Thread
i. Definition: set of processes working together harmoniously on same job, with access to same resources
ii. QUESTION: unix equivalent?
1. A: process
i. Definition: reference to a protected object
1. Origin: CTSSS files – could let someone link to your file if you wanted to grant access
2. QUESTION: good idea? How used today? Problems? (perf!, manageability)
3. QUESTION: what are limits? Revocation? Learning what access a user has?
4. QUESTION: How used today? FD list, handle table in Windows
5. QUESTION: How compare to ACLS
6. QUESTION: C-lists with reference counts: is it bad that objects go away if nobody references them? They canŐt ever be accessed.
7. QUESTION: Why need execute bit? Why is it separate than read? Why does Unix have execute but Windows does not?
a. A: entry capabilities & setuid bits
b. Avoid accidental execution of code
ii. Permissions:
1. Read, write, execute, owner
a. On reference, not on object!
2. QUESTION: why owner?
a. Allows ŇspecialÓ access, e.g. delete file, private access
iii. Usage:
1. Every process references a C-list (capability list)
2. Use capabilities by index (like file descriptor index)
3. QUESTION: how cumbersome to use?
a. May not be that bad. Defaults: cap. 1 == your directory, cap 2 = your program, everything else you store in variables.
iv. QUESTION: unix equivalent?
1. A: file descriptor (more limited)
2. A: access control list
i. Definition: a region of memory
ii. Uses: naming (segment names form global address space) + local offset
iii. Uses: protection (segment is unit of protection)
iv. Unix equivalent:
1. Address space + text, stack, heap segments
2. No control over segments in Unix
i. Definition: set of capabilities granting access
ii. QUESTION: Unix equivalent?
1. A: Address space + uid?
iii. Flexibility: can create inferior spheres with fewer rights
1. QUESTION: unix equivalent?
a. A: none
iv. Question: Why do we need these?
1. Can talk about sub-ordinate spheres (less access)
a. What good for besides debugging? Why not used?
i. A: hard to determine what rights are needed by a program
i. Definition: responsible entity for computer resource consumption (CPU, disk)
ii. QUESTION: why not used for security purposes?
1. A: capabilities used instead
iii. QUESTION: Unix equivalent?
1. User / group (but Unix doesnŐt allow charging to a group)
i. Definition: set of unique name/capability bindings
ii. Operation:
1. add (place)
2. Lookup (name -> cap) acquire
3. Release cap
4. remove (from dir)
i. No storage!
i. Provides core services – e.g. a virtual machine with more services than base hardware
1. Allocation / scheduling of resources
a. Moving data on/off disk, multiplexing access to cpu or peripherals
2. Accounting / control of resources (e.g. protection)
3. Meta-instructions (system calls or abstractions)
i. Provide further services in user-level
1. e.g. compiling
2. e.g. shared libraries
i. supervisor just provides scheduling + meta-operations
ii. I/O, other things implemented at higher levels
iii.
i. Used for naming objects + protection
1. Can create new capabilities with fewer permissions (indirectly through directories)
ii. Protection:
1. How do you protect something?
a. When created: default is only you have access
2. How do you share something?
a. Explicitly pass a capability
b. Store a capability marked Free in a directory
iii. QUESTION: how do you stop leaks?
1. A: you canŐt
2. Hard problem – called confinement
iv. QUESTION: how important is this?
1. Person you gave cap. to could proxy for someone else, copy data and release it, etc.
v. Implementation:
1. Table in the kernel
2. Tagged hardware that canŐt be manipulated
3. Allows relocating object in memory or disk (layer of indirection)
i. Automatically persistent, garbage collected
i. Lock / unlock
1. Mutual exclusion
ii. Fork / join / quit
1. Barrier synchronization
2. QUESTION: how compare with semaphores?
iii. QUESTION: unix equivalents?
1. Fork / wait
iv. QUESTION: what missing?
1. Condition variables
i. Protected entrypoints:
1. QUESTION: Why do we need these?
a. Allows amplifying rights, like setuid
b. Leads to ŇsubsystemÓ design:
2. QUESTION: What problem does this solve?
a. How to extend the system
b. How to have trusted third parties for user services
ii. Mechanism:
1. Create entrypoint
a. Snapshots current capability list
2. Invoke entrypoint
a. Launches new process with:
i. creatorŐs c-list
ii. argument capability
iii. capability to calling process
iii. Mechanism
1. Suspend caller
2. Create target process w/ capabilities to caller
a. fetch status word
b. set status word
c. continue
iv. Use:
1. Trusted subsystems
2. Can restrict access given to less-trusted code
a. Pass in directory / capability with fewer rights
v. QUESTION: Unix equivalents?
1. Setuid
i. Mechanism:
1. Create sphere
2. Add capabilities
3. Start (launch new code)
ii. New features: exceptions go to parent handler
1. WHEN: on exceptional condition (access to illegal capability, breakpoint, undefined instruction)
2. HOW: call handler routine specified on creation
3. QUESTION: how used?
a. A: allows debugging, adding new instructions
iii. Compare to Unix:
1. Create sphere = fork
2. Add capabilities = manipulate environment, fd table
3. Start = exec
i. QUESTION: why do we need naming?
1. Sharable (can give to other users)
2. Persistent (can store in program and use later)
3. Human readable
4. Unambiguous
5. Efficient (not use long names very often)
ii. Name space structure
1. Each principal gets a root
a. Directories can reference anything – any other directory or segment or entry
2. Names canŐt be changed
a. But what about removing an entry + placing a new entry with same capability?
iii. Protection of files
1. QUESTION: where is protection stored?
a. In directory: name used to access something determines access
b. Compare to Unix
2. QUESTION: how share things?
a. Can place cap. to otherŐs dir in own dir.
b. Can explicitly open other principalŐs root
i. Default: things marked ŇPÓ private available through owner capability
3. QUESTION: compare to Unix
a. A: also separates files from names
b. A: not a single rooted tree
c. Permissions not interpreted per-user, just one bit (owner / not owner)
4. QUESTION: how get richer control?
a. Write an entry that checks access + returns a cap. to a file
i. QUESTION: how done? everything is persisted by default
ii.
i. Lots of good Ôilities: security, reliability
ii. Not much discussion of important things:
1. Efficiency
2. programmability
i. Capabilty = reference + permission,