Safecode enforcing alias analysis for weakly typed languages
Download
1 / 22

safecode: enforcing alias analysis for weakly typed languages - PowerPoint PPT Presentation


  • 206 Views
  • Uploaded on

SAFECode: Enforcing Alias Analysis for Weakly Typed Languages. Dinakar Dhurjati University of Illinois at Urbana-Champaign. Joint work with Sumant Kowshik, Vikram Adve. Weakly Typed Languages (C/C++). Weak semantic guarantees

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 'safecode: enforcing alias analysis for weakly typed languages' - libitha


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
Safecode enforcing alias analysis for weakly typed languages l.jpg

SAFECode: Enforcing Alias Analysis for Weakly Typed Languages

Dinakar Dhurjati

University of Illinois at Urbana-Champaign

Joint work withSumant Kowshik, Vikram Adve


Weakly typed languages c c l.jpg
Weakly Typed Languages (C/C++) Languages

  • Weak semantic guarantees

    • Undetected array bounds errors, dangling pointer errors, type cast errors, uninitialized pointers, etc.

  • Memory safety violations

  • Any static analysis is suspect

Widely Ignored


Static analysis tools l.jpg
Static Analysis Tools Languages

Core Analyses

Alias analysis, Call graph, Type information

C program

Normal Compiler

Software Tools

(e.g. ESP, BLAST)

property

Yes or No

Memory errors invalidate core analyses


Why not use safe languages l.jpg
Why not use safe languages? Languages

Java, C#, safe dialects of C (e.g. CCured, Cyclone)

  • Large body of legacy applications in C/C++

  • Porting is not easy

    • Automatic memory management or GC

    • Wrappers for library calls because of metadata on pointers


Our solution safecode l.jpg
Our Solution: SAFECode Languages

Not a safe language :tolerates errors

  • Completely automatic, no wrappers, no GC

  • Works for nearly all C programs

  • Low overhead (less than 30% in our expts)

  • Provides sound analysis platform

    • Sound operational semantics for C based on core analyses

  • Masks dangling pointer, array bounds errors

  • Ensures memory safety (defined later)


Safecode as analysis platform l.jpg
SAFECode as Analysis Platform Languages

Alias analysis, Call graph, Type information

C program

Normal Compiler

C program

with checks

Software Verification e.g. ESP, BLAST

property

SAFECode

Yes or No

Core Analyses

SAFECode enforces core analyses, memory safety


Outline l.jpg
Outline Languages

  • Motivation & Overview

  • Background

  • Approach

  • Formalization

  • Evaluation

  • Summary


Background alias analysis l.jpg
Background - Alias Analysis Languages

head

struct List (TK)H

next val

P

Q

TUS,A

field

P = malloc(2 * sizeof(int));

P[i] = ….

struct BigT *Q = (Struct BigT *)P;

Q->field8 = …

struct List* head = makeList(20);

TK : Type Known, TU : Type Unknown

Restriction: flow-insensitive, unification based

A static summary of memory objects and their connectivity


Background automatic pool allocation apa lattneradve pldi05 l.jpg
Background - Automatic Pool Allocation (APA) Languages[LattnerAdve:PLDI05]

y

head

x

List H

List H

next val

next val

  • Each node instance uses separate pool

  • Pool is destroyed if not accessible

Pool 1

Pool 2

Partitions heap into pools based on alias analysis


Outline10 l.jpg
Outline Languages

  • Motivation & Overview

  • Background

  • Approach

  • Formalization

  • Evaluation

  • Summary


Safecode approach enforce core analyses l.jpg
SAFECode Approach : Enforce Core Analyses Languages

  • Alias analysis

  • Call graph

    • Run-time checks on indirect calls

  • Type information

    • Subset of alias analysis


Enforcing alias analysis l.jpg
Enforcing Alias Analysis Languages

tmp

struct List (TK)H

next val

  • Check if tmp points to corresponding node

  • Normal allocators

    • Memory objects are scattered in the heap

    • Each check at run-time is extremely expensive


Insight 1 use automatic pool allocation apa l.jpg
Insight 1 – Use Automatic Pool Allocation (APA) Languages

y

head

x

List H

List H

next val

next val

  • Each node instance uses separate pool

  • Pool is destroyed if not accessible

Pool 1

Pool 2

Partitions heap into pools based on alias analysis


The pool bounds check l.jpg
The Pool Bounds Check Languages

  • Pool is a list of pages (2^k)

  • Pool maintains a hash table of the start addresses of the pages

  • Poolcheck on a pointer p

    • Mask lower k bits of p, see if it is in the hash table

    • Alignment check for TK pools

Poolcheck : involves hash lookups


Insight 2 mostly static checking for tk pools l.jpg
Insight 2 : Mostly static checking for TK pools Languages

Pool bounds checks on all operations

  • Solution

    • Type homogeneity, do not release memory from pool (Insight 3)

  • Release memory from pool when pool is inaccessible (Insight 4)


Formalization as a type system l.jpg
Formalization as a Type System Languages

x

y

ρ

Int

z

ρ’

Int

poolinit (ρ, int) PP {

int*ρ x,y;

int*ρ’ z;

x = malloc(4);

y = x;

free(x);

y = malloc(4);

poolinit(ρ’, int) PP’ {

poolinit (ρ, int) PP {

int*ρ x,y;

int*ρ’ z;

x = poolalloc(PP, 1); //allocate one element

y = x; //type checks

poolfree(PP,x)

y = poolalloc(PP,1); // malloc semantics different

}

}

Soundness theorem ensures core analyses are never invalidated


Static analysis using safecode l.jpg
Static Analysis Using SAFECode Languages

e.g., ESP, BLAST

  • Flow-sensitive analysis

    • Only change is in malloc semantics

  • Flow insensitive analyses

    • don’t require any changes

Sound Analyses for C are now possible


Evaluation run time overhead l.jpg
Evaluation Languages(Run-time Overhead)

1.0 ≡ no pool allocation + no SAFECode passes

  • Olden, Ptrdist, 3 system daemons [Full list in the paper]

  • No source changes necessary

  • Compared with CCured on Olden [See paper]


Related work l.jpg
Related Work Languages

Pure C

Modified C


Two errors we don t detect l.jpg
Two errors we don’t detect Languages

  • Detecting array bounds overflow

    • A low overhead backwards-compatible solution [ICSE 2006]

  • Detecting dangling pointer dereference

    • Efficient detection for some kinds of programs [DSN 2006]


Conclusion l.jpg
Conclusion Languages

  • Sound operational semantics for C + core analyses

  • Guarantee alias analysis with low over head

  • We guarantee memory safety without detecting some errors

    - Control flow integrity

    - Data access integrity (type information)

    - Analysis integrity

http://safecode.cs.uiuc.edu


ad