UVA CS 655 - Lecture 21: Proof-Carrying Code and ||ism

Unformatted text preview:

PowerPoint PresentationMenuSlide 3Analogy: SecurityStructure of ArgumentLow-level code safetyHigh-Level Code SafetySlide 8Fortune CookieReasons you might prefer PCCConcurrencySequential ProgrammingDefinitionsConcurrent Programming LanguagesFork & JoinBjarfk (BARK with Fork & Join)Bjarfk ProgramWhat formal tool should be use to understand FORK and JOIN?Operational Semantics GameStructured Operational SemanticsSequential ConfigurationsConcurrent ConfigurationsInput Function: I: Program  CSlide 24AssignmentForkJoinWhat else is needed?Locking StatementsLocking SemanticsAcquireReleaseNew Assignment RuleAbstractionsSummaryChargeDavid Evanshttp://www.cs.virginia.edu/~evansCS655: Programming LanguagesUniversity of VirginiaComputer ScienceLecture 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 1993My 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 2Menu•INFOSEC Malicious Code Talk•ConcurrencyLet’s Stop Beating Dead Horses, and Start Beating Trojan Horses!David Evanswww.cs.virginia.edu/~evans/INFOSEC Malicious Code WorkshopSan Antonio, 13 January 2000University of VirginiaDepartment of Computer ScienceCharlottesville, VA12 April 2001 CS 655: Lecture 21 4Analogy: 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 5Structure of ArgumentLow-level code safety (isolation) is the wrong focusAgreeDisagreePCC is not a realistic solution for the real problems in the foreseeable futurePCC is not the most promising solution for low-level code safetyLots 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 6Low-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 implemented12 April 2001 CS 655: Lecture 21 7High-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 policies12 April 2001 CS 655: Lecture 21 8Proofs Reference MonitorsAll possible executions Current execution so farNo run-time costs Monitoring and calling overheadChecking integrated into codeChecking separate from codeExcruciatingly difficult Trivially easyVendor sets policy Consumer sets policy12 April 2001 CS 655: Lecture 21 9Fortune Cookie“That which be proved cannot be worth much.” Fortune cookie quoted on Peter’s web pagemustcan• True for all users• True for all executions• Exception: Low-level code safety12 April 2001 CS 655: Lecture 21 10Reasons 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 11Concurrency12 April 2001 CS 655: Lecture 21 12Sequential 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 concurrency12 April 2001 CS 655: Lecture 21 13Definitions•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 14Concurrent 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 automatically12 April 2001 CS 655: Lecture 21 15Fork & 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 16Bjarfk (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


View Full Document

UVA CS 655 - Lecture 21: Proof-Carrying Code and ||ism

Download Lecture 21: Proof-Carrying Code and ||ism
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 21: Proof-Carrying Code and ||ism and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 21: Proof-Carrying Code and ||ism 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?