metal continued
play

Metal, Continued Reading: Checking System Rules Using - PDF document

Metal, Continued Reading: Checking System Rules Using System-Specific, Programmer-Written Compiler Extensions 17-654/17-754 Analysis of Software Artifacts Jonathan Aldrich Assertion Side-Effects Flags error if assert() has side effects


  1. Metal, Continued Reading: Checking System Rules Using System-Specific, Programmer-Written Compiler Extensions 17-654/17-754 Analysis of Software Artifacts Jonathan Aldrich Assertion Side-Effects • Flags error if assert() has side effects • Illustrates matching on sub-expressions • 14 errors, 2 false positives in ExOS • Example bug: • ExOS, mmap • Causes VM fault if assert is disabled ���������������� � 1

  2. Assertion Failure Perform reaching definitions path-sensitively • • Different results for each path • At an assert statement • If reaching definition of each variable in assert is a constant assignment, evaluate the assert • Flag an error if it is false • Results • 5 errors in FLASH • Well-tested code • Def to assignment paths long and complex • e.g. 300 lines, 20 if statements, 4 else clauses, 10 conditional compilation directives ���������������� � Tainted Analysis • Kernel shouldn’t trust data from user • Could pass null references • Analysis Assume all data from user initially in tainted state • • Tainted data cannot be used except by functions that check its validity • 18 errors • 15 false positives • Example error: ���������������� � 2

  3. Memory Management • Similar to PREfix • Catch leaks, use after free, possible null dereferences • Challenge: How to do this intra-procedurally? • It’s common for procedures to return newly allocated memory • Solution • Check error return paths • OS: those returning a negative integer • Catches many (but not all) errors • PREfix can do better using interprocedural analysis ���������������� � Interprocedural analysis • Vs. PREfix • First, perform local analysis • Perform local analysis • e.g. does this function • Compute summary block? • Use summary to analyze • e.g. are interrupts callers enabled? • Handle recursion by • Later, perform reachability exploring up to a fixed analysis on call graph call depth • e.g. is a blocking • Can only track function transitively (language-level) called? information • If so, interrupts better be • Vs. Fluid enabled • Perform local analysis • Can find only simple only interprocedural errors • Use annotations to • local analysis + determine what a callee reachability does • Can track sophisticated predicates but requires user input ���������������� � 3

  4. Two Kinds of Path Sensitivity • Metal if (threads) • Explores all paths lock(y); separately • Trims paths that share do_something(); states at a program if (threads) point unlock(y) • Does not keep track of predicates • PREfix • Metal will report a • Explores all paths double-unlock error separately • False positive! • Keep track of • PREfix will not predicates • Only explores feasible paths (based on predicates) ���������������� � Comparison Focus Inter- Sound? procedural PREfix Language Summaries No errors Fluid Concurrency Annotations Yes/ errors Contingent Metal Rule violations Post-pass No ���������������� � 4

  5. Fugue: Annotations for Protocol Checking Reading: The Fugue Protocol Checker: Is Your Software Baroque? 17-654/17-754 Analysis of Software Artifacts Jonathan Aldrich Find the Bug! ���������������� �� 5

  6. Find the Bug! ���������������� �� Specifications(1) • Invariants • No resource is referenced after its release • All resources are released or returned to caller • Does this cover all uses in practice? ���������������� �� 6

  7. Specifications(2) ���������������� �� Specifications(3) ���������������� �� 7

  8. Verification [InState(“connected”, • Initial assumption WhenEnclosingState=“open”)] • WebServer closed [Unavailable(WhenEnclosingState=“ • socket unavailable closed”)] • After new Socket(…) private Socket socket; • newSock is raw • After assignment [ChangesState(“closed”, “open”)] • socket is raw public void Open (string server) { • Before Connect(…) Socket newSock • verify socket is raw or = new Socket(…); bound this.socket = newSock; • After Connect(…) IPAddress host = …; • socket is connected socket.connect(…); • End of method } • Verify Webserver open • Ok because socket is connected ���������������� �� Verification [InState(“connected”, • Initial assumption WhenEnclosingState=“open”)] • WebServer open [Unavailable(WhenEnclosingState=“ • socket connected closed”)] • Before Send(…) private Socket socket; • verify socket is connected • After Send(…) [InState(“open”)] • socket is still connected public string GetPage (string url) { • End of method this.socket.Send(…); • Verify Webserver open … • Ok because socket is } connected ���������������� �� 8

  9. Aliasing Challenges a.Open(); b.Open(); • Legal only if a != b ���������������� �� Fugue Alias Analysis • Annotations • NotAliased • Field or param is unique pointer to an object • Local variables may temporarily alias • Allows type system to track state changes • Warning (lost track of object) if assigned to Escaping parameter • MayBeAliased • May have aliases • May not call state-changing functions • If not escaping, error if assigned to field or passed to Escaping parameter • Escaping • A MayBeAliased parameter that may be (transitively) assigned to a field ���������������� �� 9

  10. Fugue Alias Analysis • Analysis information Environment env: var � addr • Capabilities: addr � aliasInfo • • aliasInfo: one of NotAliased, MayBeAliased, MayBeAliased/Escaping ���������������� �� Example: Alias Analysis void f([MayBeAliased][Escaping] x); void g([MayBeAliased] x); void h([NotAliased] y) { Environment Capabilities y � a a � NA z = y; y � a, z � a a � NA v = new T(); y � a, z � a, v � b a � NA, b � NA g(z); y � a, z � a, v � b a � NA, b � NA a still NotAliased f(v); y � a, z � a, v � b a � NA, b � MBA } Warning: lost track of b ���������������� �� 10

  11. Typestate Analysis Lattice Adapted from MSR TR and ECOOP ’04 paper to match dataflow theory Lattice element σ • ( Var � Addr , Addr � ObjDesc ) • ObjDesc: ( Type , Alias , StateSet , FieldMap ) • • State used for typestate analysis • Alias : NA, MA, MA/E FieldMap : Field � Addr • • Lattices are equivalent up to renaming of addresses • ⊑ NA ⊑ MA ⊑ MA/E • • ⊑ is ⊆ for states L 1 ⊑ L 2 if merge( α 1 , α 2 , L 1 ) ⊑ L 2 • merge substitutes α 1 for α 2 in L 1 ; joins their statesand fieldmaps, and • joins the both alias infos together with MA • Intuitively, allows more aliasing than was present before artificial ⊥ • ⊤ = ({x � α T },{ α T � (T,MA/E,states(T), f � α type(f) }) • • T = type(x) • Join Least upper bound of ⊑ • • If NA becomes MA or MA/E, warn “lost track of object” ���������������� �� Typestate Analysis Flow Functions � TA ( σ , [new T] k ) • = [t k ↦ α ][ α ↦ (T,NA,initState(T), ∅ )] σ α ∉ domain ( σ ) • � TA ( σ , [[…] n .f] k ) = [t k ↦ β ] σ • σ (t n )= α , σ ( α ).f= β • � TA ( σ , [[…] n .f] k ) = [t k ↦ β ][ β ↦ annot(f) ] σ • σ (t n )= α , f ∉ domain ( σ ( α )), β ∉ domain ( σ ), T=type(f) • annot(f) denotes the state annotated on f • � TA ( σ , [ x ] k ) = [t k ↦ σ ( x )] σ • � TA ( σ , [ x := […] n ] k ) = [ x ↦ σ (t n )] σ • � TA ( σ , /* any other */ ) = σ • ���������������� �� 11

Recommend


More recommend