David Evans cs.virginia/~evans

David Evanshttp://www.cs.virginia.edu/~evans

CS655: Programming LanguagesUniversity of VirginiaComputer Science

Lecture 21: Proof-Carrying Code and ||ismI 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.

12 April 2001 CS 655: Lecture 21 2

Menu

• INFOSEC Malicious Code Talk

• Concurrency

Let’s Stop Beating Dead Horses, and Start Beating Trojan Horses!David Evanswww.cs.virginia.edu/~evans/

INFOSEC Malicious Code Workshop

San Antonio, 13 January 2000

University of VirginiaDepartment 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]


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.


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


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


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


Fortune Cookie

“That which be proved cannot be worth much.”

Fortune cookie quoted on Peter’s web page

mustcan

• True for all users• True for all executions• Exception: Low-level code safety


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)


Concurrency


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


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?


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


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.


Bjarfk (BARK with Fork & Join)

Program ::= Instruction* Program is a sequence of instructionsInstructions 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 withThreadHandle Expression completes.

| HALT Stop thread execution.Expression ::=

Literal | Expression + Expression | Expression * Expression


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 + 1a2: R0 := R0 + 2x3: 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?


What formal tool should be use to understand FORK and

JOIN?


Operational Semantics Game

Input Function

Abstract Machine

InitialConfiguration

FinalConfiguration

Output FunctionAnswer

IntermediateConfiguration

IntermediateConfiguration

TransitionRules

Real World

Program


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 configurationsO F Answer (output function)


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]

….


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[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?


Input Function: I: Program C

C = Instructions x Threads x RegisterFile whereFor 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.


Final ConfigurationsF = 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


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 LocRegisterFile’[n] = value of Value if n Loc

Note: need rule to dealwith Loc := Expressionalso; can rewrite untilwe have a literal on RHS.


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 LocRegisterFile’[n] =

value of ThreadHandle nt if n Loc


Join <t, PCt> Threads

& Instructions[PCt] = JOIN Value

& <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}


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


Locking StatementsProgram ::= 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.


Locking Semantics

C = Instructions x Threads x RegisterFile x Locks where

Locks = { < LockHandle, ThreadHandle free,

Loc }I: Program C same as before with

Locks = { <LockHandle, free, Loc>

| PROTECT LockHandle Loc LockDeclarations }


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> }


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> }


New Assignment Rule

<t, PCt> Threads

& Instructions[PCt] = Loc := Value& ({ < LockHandle, t, Loc> } Locks | x { < LockHandle, x, Loc> } Locks

same as old assignment


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)


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


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

Documents

David Evans cs.virginia/~evans