talx86 a realistic typed assembly language
Download
Skip this Video
Download Presentation
TALx86: A Realistic Typed Assembly Language

Loading in 2 Seconds...

play fullscreen
1 / 20

TALx86: A Realistic Typed Assembly Language - PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on

s. Types. inside. TALx86: A Realistic Typed Assembly Language. Dan Grossman, Fred Smith Cornell University Joint work with: Greg Morrisett, Karl Crary (CMU), Neal Glew, Richard Samuels, Dave Walker, Stephanie Weirich, Steve Zdancewic. Everyone wants extensibility:. Web browser

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' TALx86: A Realistic Typed Assembly Language' - illiana-avila


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
talx86 a realistic typed assembly language

s

Types

inside

TALx86: A Realistic Typed Assembly Language

Dan Grossman, Fred Smith

Cornell University

Joint work with: Greg Morrisett,

Karl Crary (CMU), Neal Glew, Richard Samuels,

Dave Walker, Stephanie Weirich, Steve Zdancewic

everyone wants extensibility
Everyone wants extensibility:
  • Web browser
    • applets, plug-ins
  • OS Kernel
    • packet filters, device drivers
  • “Active” networks
    • service routines
  • Databases
    • extensible ADTs

www.cs.cornell.edu/talc

the language approach
The Language Approach

Extension is written in a “safe” language:

  • Java, Modula-3, ML, Scheme
  • Key point: language provides abstractions
    • ADTs, closures, objects, modules, etc.
    • Can be used to build fine-grained capabilities

Host ensures code respects abstractions:

  • Static checking (verification)
  • Inserting dynamic checks (code-rewriting)

www.cs.cornell.edu/talc

example your web browser
Example: Your Web Browser

JVM verifier

System

Interface

Low-Level IL

Java Source

Browser

javac

Optimizer

JVM bytecode

System

Binary

Binary

www.cs.cornell.edu/talc

jvm pros cons
JVM Pros & Cons

Pros:

  • Portability
  • Hype: $, tools, libraries, books, training

Cons:

  • Performance
    • unsatisfying, even with off-line compilation
  • Only really suitable for Java (or slight variants):
    • relatively high-level instructions tailored to Java
    • type system is Java specific
  • and...

www.cs.cornell.edu/talc

large trusted computing base
Large Trusted Computing Base

No complete

formal model

JVM verifier

System

Interface

Must insert right

checks

Low-Level IL

Browser

Good code 

big optimizer 

bugs in optimizer

Optimizer

System

Binary

Lots of “native” methods

(i.e., not-safe code)

Binary

www.cs.cornell.edu/talc

ideally
Ideally:

trusted computing base

System

Interface

Your favorite

language

verifier

System

Binary

Low-Level IL

optimizer

machine code

www.cs.cornell.edu/talc

the types way
The Types Way

trusted computing base

System

Interface

Your safe

language

verifier

System

Binary

Typed

Low-Level IL

  • Verifier is a type-checker
  • Type system flexible and expressive
  • A useful instantiation of the “proof carrying code” framework

Typed

optimizer

TAL

www.cs.cornell.edu/talc

talx86 in a nutshell
TALx86 in a Nutshell
  • Most of the IA32 80x86 flat model assembly language
  • Memory management primitives
  • Sound type system
  • Types for code, stacks, structs
  • Other advanced features
  • Future work (what we can’t do yet)

www.cs.cornell.edu/talc

talx86 basics
TALx86 Basics:

Primitive types: (e.g., int)

Code types: {r1:t1,…,rn:tn}

  • “I’m code that requires register ri to have typeti before you can jump to me.”
  • Code blocks are annotated with their types
    • Think pre-condition
    • Verify block assuming pre-condition

www.cs.cornell.edu/talc

sample loop
Sample Loop

C:

int sum(int n){

int s=0;

while(!n) {

s+=n;

--n;

}

return n;

}

TAL sketch:

<n and retn addr as input>

sum:<type>

<initialize s>

loop: <type>

<add to s, decrement n>

test: <type>

<return if n is 0>

www.cs.cornell.edu/talc

verification
Verification

sum: {ecx:int, ebx:{edx:int}}

mov eax,0

jmp test

loop:{ecx:int, ebx:{edx:int}, eax:int}

add eax,ecx

dec ecx

test:{ecx:int, ebx:{edx:int}, eax:int}

cmp ecx,0

jne loop

mov edx,eax

jmp ebx

{ecx:int, ebx:{edx:int}, eax:int}

OK: sub-type of type labeling test

{ecx:int, ebx:{edx:int}, eax:int}

{ecx:int, ebx:{edx:int}, eax:int}

OK: sub-type of type labeling next block

{ecx:int, ebx:{edx:int}, eax:int}

OK: sub-type of type labeling loop

{ecx:int, ebx:{edx:int}, eax:int, edx:int}

OK: sub-type of {edx:int} -- type of ebx

www.cs.cornell.edu/talc

stacks procedures
Stacks & Procedures

Stack Types (lists):

s ::= nil | t::s | r

where r is a stack type variable.

Examples using C calling convention:

int square(int); int mult(int,int);

"r1{esp: t1::int::r1} "r2{esp: t2::int::int::r2}

where where

t1={eax: int, esp: int::r1} t2={eax: int, esp: int::int::r2}

www.cs.cornell.edu/talc

stacks verification

r1

int

t1

int

int

taft

Stacks & Verification

square:"r1{esp: t1::int::r1}

where t1={eax: int, esp: int::r1}

push [esp+4]

push [esp+8]

call mult[with r2 = t1::int::r1]

add esp,8

retn

mult:"r2{esp: t2::int::int::r2}

where t2={eax: int, esp: int::int::r2}

taft={eax:int, esp: int::int::t1::int::r1}

{esp:t2::int::int::t1::int::r1}

wheret2={eax: int, esp: int::int::t1::int::r1}

www.cs.cornell.edu/talc

important properties
Important Properties
  • Abstraction

“Because the type of the rest of the stack is abstract the callee cannot read/write this portion of the stack”

  • Flexibility

Can encode and enforce many calling conventions

(stack shape on return, callee-save, tail calls, etc.)

www.cs.cornell.edu/talc

callee save example
Callee-Save Example

mult:

"a"r2{ebp: a, esp: t2::int::int::r2}

where t2={ebp: a, eax: int, esp: int::int::r2}

www.cs.cornell.edu/talc

structs
Structs
  • Goals:
    • Prevent reading uninitialized fields
    • Permit flexible scheduling of initialization
  • MALLOC “instruction”

returns uninitialized record

  • Type of struct tracks initialization of fields
  • Example:{ecx: int}

MALLOC eax,8 [int,int]; eax : ^*[intu, intu]

mov [eax+0], ecx ; eax : ^*[intrw,intu]

mov ecx, [eax+4] ; type error!

www.cs.cornell.edu/talc

much much more
Much, much more
  • Arrays (see next slide)
  • Tagged Unions
  • Displays, Exceptions [TIC’98]
  • Static Data
  • Modules and Interfaces [POPL’99]
  • Run-time code generation [PEPM’99 Jim, Hornof]

www.cs.cornell.edu/talc

mis features
Mis-features
  • MALLOC and garbage collection in trusted computing base [POPL’99]
  • No way to express aliasing
  • No array bounds check elimination [Walker]
  • Object/class support too primitive [Glew]

www.cs.cornell.edu/talc

summary and conclusions
Summary and Conclusions
  • We can type real machine code

Potential for performance + flexibility + safety

  • Challenge:

Finding generally useful abstractions

  • Lots of work remains

http://www.cs.cornell.edu/talc

www.cs.cornell.edu/talc

ad