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 CS655 Programming Languages University of Virginia David Evans Computer Science http www cs virginia edu evans Menu INFOSEC Malicious Code Talk Concurrency 12 April 2001 CS 655 Lecture 21 2 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 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 12 April 2001 CS 655 Lecture 21 4 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 lowlevel code safety Lots of useful research and results coming from PCC but realistic solution to malicious code won t be one of them 12 April 2001 CS 655 Lecture 21 5 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 12 April 2001 CS 655 Lecture 21 6 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 12 April 2001 CS 655 Lecture 21 7 Proofs Reference Monitors All possible executions Current execution so far No run time costs Monitoring and calling overhead Checking integrated into code Checking separate from code Excruciatingly difficult Trivially easy Vendor sets policy Consumer sets policy 12 April 2001 CS 655 Lecture 21 8 Fortune Cookie That which must can 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 12 April 2001 CS 655 Lecture 21 9 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 12 April 2001 CS 655 Lecture 21 10 Concurrency 12 April 2001 CS 655 Lecture 21 11 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 12 April 2001 CS 655 Lecture 21 12 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 12 April 2001 CS 655 Lecture 21 13 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 12 April 2001 CS 655 Lecture 21 14 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 12 April 2001 CS 655 Lecture 21 15 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 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 12 April 2001 CS 655 Lecture 21 16 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 12 April 2001 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 CS 655 Lecture 21 17 What formal tool should be use to understand FORK and JOIN 12 April 2001 CS 655 Lecture 21 18 Operational Semantics Game Real World Program Abstract Machine Input Function Transition Rules Initial Configuration Intermediate Configuration Intermediate Configuration Answer 12 April 2001 Output Function CS 655 Lecture 21 Final Configuration 19 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