safecode enforcing alias analysis for weakly typed languages
Download
Skip this Video
Download Presentation
SAFECode: Enforcing Alias Analysis for Weakly Typed Languages

Loading in 2 Seconds...

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

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
Weakly Typed Languages (C/C++)
  • 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
Static Analysis Tools

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
Why not use safe 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
Our Solution: SAFECode

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
SAFECode as Analysis Platform

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
Outline
  • Motivation & Overview
  • Background
  • Approach
  • Formalization
  • Evaluation
  • Summary
background alias analysis
Background - Alias Analysis

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
Background - Automatic Pool Allocation (APA)[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
Outline
  • Motivation & Overview
  • Background
  • Approach
  • Formalization
  • Evaluation
  • Summary
safecode approach enforce core analyses
SAFECode Approach : Enforce Core Analyses
  • Alias analysis
  • Call graph
    • Run-time checks on indirect calls
  • Type information
    • Subset of alias analysis
enforcing alias analysis
Enforcing Alias Analysis

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
Insight 1 – Use Automatic Pool Allocation (APA)

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
The Pool Bounds Check
  • 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
Insight 2 : Mostly static checking for TK pools

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
Formalization as a Type System

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
Static Analysis Using SAFECode

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
Evaluation (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
Related Work

Pure C

Modified C

two errors we don t detect
Two errors we don’t detect
  • 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
Conclusion
  • 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