1 / 36

David Evans cs.virginia/~evans

Lecture 21: Proof-Carrying Code and ||ism. I don’t think we have found the right programming concepts for parallel computers yet. When we do, they will almost certainly be very different from anything we know today. Birch Hansen, “Concurrent Pascal” (last sentence), HOPL 1993

verlee
Télécharger la présentation

David Evans cs.virginia/~evans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 21: Proof-Carrying Code and ||ism I don’t think we have found the right programming concepts for parallel computers yet. When we do, they will almost certainly be very different from anything we know today. Birch Hansen, “Concurrent Pascal” (last sentence), HOPL 1993 My only serious debate with your account is with the very last sentence. I do not believe there is any “right” collection of programming concepts for parallel (or even sequential) computers. The design of a language is always a compromise, in which the designer must take into account the desired level of abstraction, the target machine architecture, and the proposed range of applications. C. A. R. Hoare, comment at HOPL II 1993. David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science

  2. Menu • INFOSEC Malicious Code Talk • Concurrency CS 655: Lecture 21

  3. Let’s Stop Beating Dead Horses, and Start Beating Trojan Horses! David Evans www.cs.virginia.edu/~evans/ INFOSEC Malicious Code Workshop San Antonio, 13 January 2000 University of Virginia Department of Computer Science Charlottesville, VA

  4. Analogy: Security • Cryptography • Fun to do research in, lots of cool math problems, opportunities to dazzle people with your brilliance, etc. • But, 99.9999% of break ins do not involve attack on sensible cryptography • Guessing passwords and stealing keys • Back doors, buffer overflows • Ignorant implementers choosing bad cryptography [Netscape Navigator Mail] CS 655: Lecture 21

  5. Structure of Argument Low-level code safety (isolation) is the wrong focus Agree Disagree PCC is not a realistic solution for the real problems in the foreseeable future PCC is not the most promising solution for low-level code safety Lots of useful research and results coming from PCC, but realistic solution to malicious code won’t be one of them. CS 655: Lecture 21

  6. Low-level code safety • Type safety, memory safety, control flow safety [Kozen98] • All high-level code safety depends on it • Many known pretty good solutions: separate processes, SFI, interpreter • Very few real attacks exploit low-level code safety vulnerabilities • One exception: buffer overflows • Many known solutions to this • Just need to sue vendors to get them implemented CS 655: Lecture 21

  7. High-Level Code Safety • Enforcement is (embarrassingly) easy • Reference monitors (since 1970s) • Can enforce most useful policies [Schneider98] • Performance penalty is small • Writing good policies is the hard part • Better ways to define policies • Ways to reason about properties of policies • Ideas for the right policies for different scenarios • Ways to develop, reason about, and test distributed policies CS 655: Lecture 21

  8. CS 655: Lecture 21

  9. Fortune Cookie must can “That which be proved cannot be worth much.” Fortune cookie quoted on Peter’s web page • True for all users • True for all executions • Exception: Low-level code safety CS 655: Lecture 21

  10. Reasons you might prefer PCC • Run-time performance? • Amortizes additional download and verification time only rarely • SFI Performance penalty: ~5% • If you care, pay $20 more for a better processor or wait 5 weeks • Smaller TCB? • Not really smaller: twice as big as SFI (Touchstone VCGen+checker – 8300 lines / MisFiT x86 SFI implementation – 4500 lines) • You are a vendor who cares more about quality than time to market (not really PCC) CS 655: Lecture 21

  11. Concurrency CS 655: Lecture 21

  12. Sequential Programming • So far, most languages we have seen provide a sequential programming model: • Language definition specifies a sequential order of execution • Language implementation may attempt to parallelize programs, but they must behave as though they are sequential • Exceptions: Algol68, Ada, Java include support for concurrency CS 655: Lecture 21

  13. Definitions • Concurrency – any model of computation supporting partially ordered time. (Semantic notion) • Parallelism – hardware that can execute multiple threads simultaneously (Pragmatic notion) • Can you have concurrency without parallelism? • Can you have parallelism without concurrency? CS 655: Lecture 21

  14. Concurrent Programming Languages • Expose multiple threads to programmer • Some problems are clearer to program using explicit parallelism • Modularity • Don’t have to explicitly interleave code for different abstractions • High-level interactions – synchronization, communication • Modelling • Closer map to real world problems • Provide performance benefits of parallelism when compiler could not find it automatically CS 655: Lecture 21

  15. Fork & Join • Concurrency Primitives: • forkE ThreadHandle • Creates a new thread that evaluates Expression E; returns a unique handle identifying that thread. • joinT • Waits for thread identified by ThreadHandle T to complete. CS 655: Lecture 21

  16. Bjarfk (BARK with Fork & Join) Program ::= Instruction* Program is a sequence of instructions Instructions are numbered from 0. Execution begins at instruction 0, and completes with the initial thread halts. Instruction ::= Loc := ExpressionLoc gets the value of Expression | Loc := FORK Expression Loc gets the value of the ThreadHandle returned by FORK; Starts a new thread at instruction numbered Expression. | JOIN Expression Waits until thread associated with ThreadHandle Expression completes. | HALT Stop thread execution. Expression ::= Literal | Expression + Expression | Expression * Expression CS 655: Lecture 21

  17. Bjarfk Program Atomic instructions: a1: R0 := R0 + 1 a2: R0 := R0 + 2 x3: R0 := R0 * 3 Partial Ordering: a1 <= x3 So possible results are, (a1, a2, x3) = 12 (a2, a1, x3) = 9 (a1, x3, a2) = 12 What if assignment instructions are not atomic? [0] R0 := 1 [1] R1 := FORK 10 [2] R2 := FORK 20 [3] JOIN R1 [4] R0 := R0 * 3 [5] JOIN R2 [6] HALT % result in R0 [10] R0 := R0 + 1 [11] HALT [20] R0 := R0 * 2 [21] HALT CS 655: Lecture 21

  18. What formal tool should be use to understand FORK and JOIN? CS 655: Lecture 21

  19. Operational Semantics Game Real World Abstract Machine Program Initial Configuration Input Function Intermediate Configuration Transition Rules Intermediate Configuration Answer Final Configuration Output Function CS 655: Lecture 21

  20. Structured Operational Semantics SOS for a language is five-tuple: CSet of configurations for an abstract machine  Transition relation (subset of C x C) I Program  C (input function) F Set of final configurations OF  Answer (output function) CS 655: Lecture 21

  21. Sequential Configurations Configuration defined by: • Array of Instructions • Program counter • Values in registers (any integer) C = Instructions x PC x RegisterFile …. …. Instruction[-1] Register[-1] Instruction[0] Register[0] PC Instruction[1] Register[1] Instruction[2] Register[2] …. …. CS 655: Lecture 21

  22. Concurrent Configurations Configuration defined by: • Array of Instructions • Array of Threads Thread = < ThreadHandle, PC > • Values in registers (any integer) C = Instructions x Threads x RegisterFile …. …. Instruction[-1] Register[-1] Instruction[0] Register[0] Thread 1 Instruction[1] Register[1] Instruction[2] Register[2] Thread 2 …. …. Architecture question: Is this SIMD/MIMD/SISD/MISD model? CS 655: Lecture 21

  23. Input Function: I: Program  C C = Instructions x Threads x RegisterFile where For a Program with n instructions from 0 to n - 1:Instructions[m] = Program[m] for m >= 0 && m < n Instructions[m] = ERROR otherwise RegisterFile[n] = 0 for all integers n Threads = [ <0, 0> ] The top thread (identified with ThreadHandle = 0) starts at PC = 0. CS 655: Lecture 21

  24. Final Configurations F = Instructions x Threads x RegisterFile where <0, PC>  Threads and Instructions[PC] = HALT Different possibility: F = Instructions x Threads x RegisterFile where for all <t, PCt>  Threads, Instructions[PCt] = HALT CS 655: Lecture 21

  25. Note: need rule to deal with Loc := Expression also; can rewrite until we have a literal on RHS. Assignment <t, PCt>  Threads & Instructions[PCt] = Loc := Value < Instructions x Threads x RegisterFile >  < Instructions x Threads’ x RegisterFile’ > where Threads = Threads – {<t, PCt>} + {<t, PCt + 1} RegisterFile’[n] = RegisterFile[n] if n  Loc RegisterFile’[n] = value of Value if n  Loc CS 655: Lecture 21

  26. Fork <t, PCt>  Threads & Instructions[PCt] = Loc := FORK Literal < Instructions x Threads x RegisterFile >  < Instructions x Threads’ x RegisterFile’ > where Threads = Threads – {<t, PCt>} + {<t, PCt + 1} + { <nt, Literal> } where <nt, x> Threads for all possible x. RegisterFile’[n] = RegisterFile[n] if n  Loc RegisterFile’[n] = value of ThreadHandle nt if n  Loc CS 655: Lecture 21

  27. Join <t, PCt>  Threads & Instructions[PCt] = JOINValue & <v, PCv>  Threads & Instructions[PCv ] = HALT & v = value of Value < Instructions x Threads x RegisterFile >  < Instructions x Threads’ x RegisterFile > where Threads = Threads – {<t, PCt>} + {<t, PCt + 1} CS 655: Lecture 21

  28. What else is needed? • Can we build all the useful concurrency primitives we need using FORK and JOIN? • Can we implement a semaphore? • No, need an atomic test and acquire operation CS 655: Lecture 21

  29. Locking Statements Program ::= LockDeclaration* Instruction* LockDeclaration ::= PROTECT LockHandleLoc Prohibits reading or writing location Loc in a thread that does not hold the loc LockHandle. Instruction ::= ACQUIRE LockHandle Acquires the lock identified by LockHandle. If another thread has acquired the lock, thread stalls until lock is available. Instruction ::= RELEASE LockHandle Releases the lock identified by LockHandle. CS 655: Lecture 21

  30. Locking Semantics C = Instructions x Threads x RegisterFile x Lockswhere Locks = { < LockHandle, ThreadHandle  free, Loc } I: Program  C same as before with Locks = { <LockHandle, free, Loc> | PROTECT LockHandle Loc  LockDeclarations } CS 655: Lecture 21

  31. Acquire <t, PCt>  Threads & Instructions[PCt] = ACQUIRE LockHandle & { < LockHandle, free, S> }  Locks < Instructions x Threads x RegisterFile x Locks >  < Instructions x Threads’ x RegisterFile x Locks’ > where Threads = Threads – {<t, PCt>} + {<t, PCt + 1}; Locks’= Locks – {< LockHandle, free, S>} + {<LockHandle, t, S> } CS 655: Lecture 21

  32. Release <t, PCt>  Threads & Instructions[PCt] = RELEASE LockHandle & { < LockHandle, t, S> }  Locks < Instructions x Threads x RegisterFile x Locks >  < Instructions x Threads’ x RegisterFile x Locks’ > where Threads = Threads – {<t, PCt>} + {<t, PCt + 1}; Locks’= Locks – {< LockHandle, t, S>} + {<LockHandle, free, S> } CS 655: Lecture 21

  33. New Assignment Rule <t, PCt>  Threads & Instructions[PCt] = Loc := Value & ({ < LockHandle, t, Loc> }  Locks | x { < LockHandle, x, Loc> }  Locks same as old assignment CS 655: Lecture 21

  34. Abstractions • Can we describe common concurrency abstractions using only our primitives? • Binary semaphore: equivalent to our ACQUIRE/RELEASE • Monitor: abstraction using a lock • But no way to set thread priorities with our mechanisms (operational semantics gives no guarantees about which rule is used when multiple rules match) CS 655: Lecture 21

  35. Summary • Hundreds of different concurrent programming languages • [Bal, Steiner, Tanenbaum 1989] lists over 200 papers on 100 different concurrent languages! • Primitives are easy (fork, join, acquire, release), finding the right abstractions is hard CS 655: Lecture 21

  36. Charge • Linda Papers • Describes an original approach to concurrent programming • Basis for Sun’s JavaSpaces technology (framework for distributed computing using Jini) • Project progress • Everyone should have received a reply from me about your progress email CS 655: Lecture 21

More Related