Programming Semantics for Multiprogrammed Computations

Dennis & Van Horn

 

 

  1. Comments on layering:
    1. Show concentric circles (whole system is layers, rigid layering), vs subsystem as layers
    2. Layering a subsystem provides:

                                              i.     Standard interfaces

                                             ii.     Standard extension points

                                           iii.     Tree-like/graph like structures because layers are replaceable

    1. Layering a whole OS (concentric circles)

                                              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

  1. Context:
    1. Designing an information utility – a multi access computer
    2. Lots of users doing time sharing

                                              i.     Goal: System to satisfy all needs, and be flexible in future.

    1. Looking at how do you write programs for this kind of computer – what are the primitives needed
    2. Up to now, previous systems hadnŐt offered much for semantics:

                                              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

    1. Goal: kernel written in HLL, higher level programs in any language
    2. Multics System ran 55 concurrent users, with ~1-5 second response time, up 22x7, average 1-2 crashes/24 hours
    3. Note: system never implemented, but portions of it went into Multics.

                                              i.     Details of sharing segments & linking fairly complex

    1.  
  1. Material from reviews:
    1. Problem:

                                              i.     efficient sharing, protection, utilization

    1. Contributions:

                                              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?

    1. Flaws:

                                              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

 

  1. Goals:
    1. QUESTION: What is the goal of this system?

                                              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?

    1. Figuring out the right primitives to accomplish this

                                              i.     What structures/units are needed: e.g. process, computation, segment, etc.

                                             ii.     What operations are needed

  1. Summary:
    1. QUESTION: what are the services MAC provides? Why these?
    2. Services OS must provide:

                                              i.     Parallel processing

                                             ii.     Naming object of computation so can be referenced/shared

                                           iii.     Protection

    1. Question: What are the properties of a multiprogramming system?
    2. Multiprogramming properties:

                                              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

  1. What are the abstractions?

                                              i.     Note: will compare against Unix

    1. Process

                                              i.     Definition: locus of control within an instruction sequence

                                             ii.     QUESTION: what is Unix equivalent?

1.   A: Thread

    1. Computation

                                              i.     Definition: set of processes working together harmoniously on same job, with access to same resources

                                             ii.     QUESTION: unix equivalent?

1.   A: process

    1. Capability

                                              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

    1. Segment

                                              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

    1. Sphere of protection:

                                              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

    1. Principal:

                                              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)

    1. Directories

                                              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)

    1. COMMENTS:

                                              i.     No storage!

  1. System structure
    1. Supervisor / nucleus / kernel

                                              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)

    1. Protected entrypoints

                                              i.     Provide further services in user-level

1.   e.g. compiling

2.   e.g. shared libraries

    1. Result: microkernel

                                              i.     supervisor just provides scheduling + meta-operations

                                             ii.     I/O, other things implemented at higher levels

                                           iii.      

  1. Semantics for the primitives
    1. Capabilities

                                              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)

    1. Segments

                                              i.     Automatically persistent, garbage collected

    1. Coordination

                                              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

    1. Control transfer

                                              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

    1. Inferior sphere

                                              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

    1. Naming:

                                              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

    1. Storage / Files

                                              i.     QUESTION: how done? everything is persisted by default

                                             ii.      

  1. QUESTIONS:

                                              i.     Lots of good Ôilities: security, reliability

                                             ii.     Not much discussion of important things:

1.   Efficiency

2.   programmability

  1. Big ideas:
    1. spheres of protection, subordinate spheres
    2. trapping to superior sphere for extensibility/control
    3. capabilities for everything

                                              i.     Capabilty = reference + permission,

    1. multiprocessing primitives
    2. subsystem design for shared services
    3. Hierarchical directories for naming – with hard/soft links!
    4. Enter capabilities = protected procedure calls