David evans http www cs virginia edu evans
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

David Evans cs.virginia/~evans PowerPoint PPT Presentation


  • 32 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


David evans http www cs virginia edu 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

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


David evans cs virginia evans

Menu

  • INFOSEC Malicious Code Talk

  • Concurrency

CS 655: Lecture 21


David evans cs virginia evans

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

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


Structure of argument

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


Low level code safety

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


High level code safety

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


David evans cs virginia evans

CS 655: Lecture 21


Fortune cookie

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


Reasons you might prefer pcc

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


Concurrency

Concurrency

CS 655: Lecture 21


Sequential programming

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


Definitions

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


Concurrent programming languages

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


Fork join

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


Bjarfk bark with fork join

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

CS 655: Lecture 21


Bjarfk program

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


What formal tool should be use to understand fork and join

What formal tool should be use to understand FORK and JOIN?

CS 655: Lecture 21


Operational semantics game

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


Structured operational semantics

Structured Operational Semantics

SOS for a language is five-tuple:

CSet of configurations for an abstract machine

Transition relation (subset of C x C)

IProgram  C(input function)

FSet of final configurations

OF  Answer(output function)

CS 655: Lecture 21


Sequential configurations

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


Concurrent configurations

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


Input function i program c

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


David evans cs virginia evans

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


Assignment

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


David evans cs virginia evans

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


David evans cs virginia evans

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


What else is needed

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


Locking statements

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


Locking semantics

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


Acquire

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


Release

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


New assignment rule

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


Abstractions

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


Summary

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


Charge

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


  • Login