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
David Evans
University of Virginia
http://www.cs.virginia.edu/~evans
Computer Science
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*
Instruction ::= Loc := Expression
| Loc := FORK Expression
| JOIN Expression
Program is a sequence of instructions
Instructions are numbered from 0.
Execution begins at instruction 0, and
completes with the initial thread halts.
Loc gets the value of Expression
Loc gets the value of the
ThreadHandle returned by FORK;
Starts a new thread at instruction
numbered Expression.
Waits until thread associated with
ThreadHandle Expression completes.
Stop thread execution.
| HALT
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

I
F
O
Set of configurations for an abstract machine
Transition relation (subset of C x C)
Program  C (input function)
Set of final configurations
F  Answer (output function)
12 April 2001
CS 655: Lecture 21
20
Sequential Configurations
Configuration defined by:
– Array of Instructions
– Program counter
– Values in registers
(any integer)
PC
….
….
Instruction[-1]
Register[-1]
Instruction[0]
Register[0]
Instruction[1]
Register[1]
Instruction[2]
Register[2]
….
….
C = Instructions x PC x RegisterFile
12 April 2001
CS 655: Lecture 21
21
Concurrent Configurations
Configuration defined by:
– Array of Instructions
– Array of Threads
Thread 1
Thread = < ThreadHandle, PC >
– Values in registers
(any integer)
Thread 2
….
….
Instruction[-1]
Register[-1]
Instruction[0]
Register[0]
Instruction[1]
Register[1]
Instruction[2]
Register[2]
….
….
C = Instructions x Threads x RegisterFile
Architecture question: Is this SIMD/MIMD/SISD/MISD model?
12 April 2001
CS 655: Lecture 21
22
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.
12 April 2001
CS 655: Lecture 21
23
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
12 April 2001
CS 655: Lecture 21
24
Assignment
Note: need rule to deal
with Loc := Expression
also; can rewrite until
we have a literal on RHS.
<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
12 April 2001
CS 655: Lecture 21
25
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
12 April 2001
CS 655: Lecture 21
26
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}
12 April 2001
CS 655: Lecture 21
27
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
12 April 2001
CS 655: Lecture 21
28
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.
12 April 2001
CS 655: Lecture 21
29
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 }
12 April 2001
CS 655: Lecture 21
30
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> }
12 April 2001
CS 655: Lecture 21
31
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> }
12 April 2001
CS 655: Lecture 21
32
New Assignment Rule
<t, PCt>  Threads
& Instructions[PCt] = Loc := Value
& ({ < LockHandle, t, Loc> }  Locks
| x { < LockHandle, x, Loc> }  Locks
same as old assignment
12 April 2001
CS 655: Lecture 21
33
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)
12 April 2001
CS 655: Lecture 21
34
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
12 April 2001
CS 655: Lecture 21
35
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
12 April 2001
CS 655: Lecture 21
36