1. David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science 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.

2. 12 April 2001CS 655: Lecture 212 Menu INFOSEC Malicious Code Talk Concurrency

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. 12 April 2001CS 655: Lecture 214 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]

5. 12 April 2001CS 655: Lecture 215 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.

6. 12 April 2001CS 655: Lecture 216 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

7. 12 April 2001CS 655: Lecture 217 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

8. 12 April 2001CS 655: Lecture 218 ProofsReference Monitors All possible executionsCurrent execution so far No run-time costsMonitoring and calling overhead Checking integrated into code Checking separate from code Excruciatingly difficultTrivially easy Vendor sets policyConsumer sets policy

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

10. 12 April 2001CS 655: Lecture 2110 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)

11. 12 April 2001CS 655: Lecture 2111 Concurrency

12. 12 April 2001CS 655: Lecture 2112 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

13. 12 April 2001CS 655: Lecture 2113 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?

14. 12 April 2001CS 655: Lecture 2114 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

15. 12 April 2001CS 655: Lecture 2115 Fork & Join Concurrency Primitives: –fork E  ThreadHandle Creates a new thread that evaluates Expression E; returns a unique handle identifying that thread. –join T Waits for thread identified by ThreadHandle T to complete.

16. 12 April 2001CS 655: Lecture 2116 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 := Expression Loc gets the value of Expression | Loc := FORK ExpressionLoc 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. | HALTStop thread execution. Expression ::= Literal | Expression + Expression | Expression * Expression

17. 12 April 2001CS 655: Lecture 2117 Bjarfk Program [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 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?

18. 12 April 2001CS 655: Lecture 2118 What formal tool should be use to understand FORK and JOIN?

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

20. 12 April 2001CS 655: Lecture 2120 Structured Operational Semantics SOS for a language is five-tuple: C Set 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)

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

22. 12 April 2001CS 655: Lecture 2122 Concurrent Configurations Configuration defined by: –Array of Instructions –Array of Threads Thread = –Values in registers (any integer) C = Instructions x Threads x RegisterFile Instruction[0] Instruction[1] Instruction[2] …. Instruction[-1] …. Thread 1 Register[0] Register[1] Register[2] …. Register[-1] …. Thread 2 Architecture question: Is this SIMD/MIMD/SISD/MISD model?

23. 12 April 2001CS 655: Lecture 2123 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 = [ ] The top thread (identified with ThreadHandle = 0) starts at PC = 0.

24. 12 April 2001CS 655: Lecture 2124 Final Configurations F = Instructions x Threads x RegisterFile where  Threads and Instructions [PC] = HALT Different possibility: F = Instructions x Threads x RegisterFile where for all  Threads, Instructions [PC t ] = HALT

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

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

27. 12 April 2001CS 655: Lecture 2127 Join  Threads & Instructions[PC t ] = JOIN Value &  Threads & Instructions[PC v ] = HALT & v = value of Value  where Threads = Threads – { } + {<t, PC t + 1}

28. 12 April 2001CS 655: Lecture 2128 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

29. 12 April 2001CS 655: Lecture 2129 Locking Statements Program ::= LockDeclaration* Instruction* LockDeclaration ::= PROTECT LockHandle Loc 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.

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

31. 12 April 2001CS 655: Lecture 2131 Acquire  Threads & Instructions[PC t ] = ACQUIRE LockHandle & { }  Locks  where Threads = Threads – { } + {<t, PC t + 1}; Locks’= Locks – { } + { }

32. 12 April 2001CS 655: Lecture 2132 Release  Threads & Instructions[PC t ] = RELEASE LockHandle & { }  Locks  where Threads = Threads – { } + {<t, PC t + 1}; Locks’= Locks – { } + { }

33. 12 April 2001CS 655: Lecture 2133 New Assignment Rule  Threads & Instructions[PC t ] = Loc := Value & ({ }  Locks |  x { }  Locks same as old assignment

34. 12 April 2001CS 655: Lecture 2134 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)

35. 12 April 2001CS 655: Lecture 2135 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

36. 12 April 2001CS 655: Lecture 2136 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