Certified Memory Usage Analysis

Transcription

1 Certified Memory Usage Analysis David Cachera, Thomas Jensen, David Pichardie, Gerardo Schneider IRISA, ENS Cachan Bretagne, France

2 Context Embedded devices (smart cards, mobile phones) memory is limited garbage collectors are time and memory consuming Industrial answer : smart cards programmers are not allowed to make dynamical allocation inside loops!

3 Goal of this work Propose a static analysis aimed at verifying that the number of dynamical allocations is bounded loop detection algorithm This analysis targets programs written using the previous restrictive programming discipline dynamical loops are over-approximated by static loops a program is predicted memory bounded if no dynamical allocation occurs inside static loops

4 Why you should not read this paper... you are looking for a sophisticated memory usage analysis you are only interested in implementing verification tools you don t care about proofs

5 Why you should not read this paper... you are looking for a sophisticated memory usage analysis you are only interested in implementing verification tools you don t care about proofs A simple algorithm, but an in-extenso correctness proof of the algorithm based on the abstract interpretation theory machine-checked in the Coq proof assistant efficient implementation extracted from the proof

6 Outline Introduction The analysed language The algorithm Certification Experimental results Conclusion

7 Outline Introduction The analysed language The algorithm Certification Experimental results Conclusion

8 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

9 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

10 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

11 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

12 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

13 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

14 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine 4 kinds of instructions intra-method jumps inter-method jumps dynamical allocation the others... nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

15 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine 4 kinds of instructions intra-method jumps inter-method jumps dynamical allocation the others... nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

16 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine 4 kinds of instructions intra-method jumps inter-method jumps dynamical allocation the others... nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

17 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine 4 kinds of instructions intra-method jumps inter-method jumps dynamical allocation the others... nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

18 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine 4 kinds of instructions intra-method jumps inter-method jumps dynamical allocation the others... nop push c pop swap numop op load x store x if pc goto pc new cl putfield f getfield f newarray t arraylength arrayload arraystore invokevirtual m id return stack } local variables } jump heap } method call and return

19 The analysed language : Carmel Instructions an intermediate representation of the Java Card bytecode bytecode for stack machine 4 kinds of instructions intra-method jumps inter-method jumps dynamical allocation the others... instr in the rest of the talk instr instr instr instr instr instr instr if pc goto pc new cl instr instr newarray t instr instr instr invokevirtual m id return stack } local variables } jump heap } method call and return

20 Carmel : semantic domains Val ::= num n n N ref r r Reference null Stack = Val LocalVar = Var Val Frame = NameMethod PointProg LocalVar Stack CallStack = Frame Object = FieldName Val Heap = Reference Object State = Heap Frame CallStack State example : h, m, pc, l, v :: s, sf

21 Carmel : operational semantics instructionat P (m, pc) = instr h, m, pc, l, s, sf h, m, pc + 1, l, s, sf instructionat P (m, pc) = invokevirtual m id m = methodlookup(m id, h(loc)) V = v 1 :: :: v nbarguments(mid ) h, m, pc, l, loc :: V :: s, sf h, m, 1, V, ε, m, pc, l, s :: sf

22 Carmel : reachable partial traces Sequence of consecutive states P = { s 0 :: s 1 :: :: s n State + s 0 S init k < n, s k s k+1 } (State + ) with S init : set of initial states

23 Carmel : reachable partial traces Sequence of consecutive states P = { s 0 :: s 1 :: :: s n State + s 0 S init k < n, s k s k+1 } (State + ) with S init : set of initial states Our static analysis aims at computing an over-approximation of P

24 Outline Introduction The analysed language The algorithm Certification Experimental results Conclusion

25 Algorithm : outline

26 Algorithm : outline Two graphs

27 Algorithm : outline Two graphs method call graph

28 Algorithm : outline Two graphs method call graph internal flow graph

29 Algorithm : outline Two graphs method call graph internal flow graph 4 steps

30 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph

31 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph

32 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph 3. detection of dangerous zones

33 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph 3. detection of dangerous zones loop zone in both graphs

34 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph 3. detection of dangerous zones loop zone in both graphs successors of loop zone

35 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph 3. detection of dangerous zones loop zone in both graphs successors of loop zone 4. last check : no allocation inside dangerous zones

36 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph 3. detection of dangerous zones loop zone in both graphs successors of loop zone 4. last check : no allocation inside dangerous zones new new Memory bounded

37 Algorithm : outline Two graphs method call graph internal flow graph 4 steps 1. loop detection in method call graph 2. loop detection in internal flow graph new 3. detection of dangerous zones loop zone in both graphs successors of loop zone 4. last check : no allocation Memory maybe unbounded inside dangerous zones new

38 Algorithm : the steps Formalised as a sequence of constraint on 5 variables (living in lattice structures) 1. Potential ancestors of each methods in the call graph Anc : NameMethod (NameMethod) (m, pc) : invokevirtual m ID m implements(p, m ID ) Anc(m) {m} Anc(m ) 2. Determining which methods are reachable from a mutually recursive method MutRecR : (NameMethod) m Anc(m) {m} MutRecR Anc(m) MutRecR {m} MutRecR

39 Algorithm : the steps 3. For each program point (m, pc), computing the potential predecessors in the internal flow graph Pred : NameMethod PointProg (PointProg) 4. Determining methods reachable from internal loops LoopCall : (NameMethod) 5. Check that no new instruction occurs in any dangerous zone Unbounded(P) : Bool (m, pc) : new o cl m MutRecR m LoopCall pc Pred(m, pc) true Bool Unbounded(P)

40 Outline Introduction The analysed language The algorithm Certification Experimental results Conclusion

41 Certification Approach based on the abstract interpretation formalism : we show that the informations computed with the constraints system are correct with respect to the program semantics. Concrete semantics Abstract semantics t : s 0 :: s 1 :: :: s n Anc : m 1 {} m 2 {m 1 } m 3 {m 2, m 3 } m 4 {m 3 }.

42 Certification Approach based on the abstract interpretation formalism : we show that the informations computed with the constraints system are correct with respect to the program semantics. Concrete semantics Abstract semantics t : s 0 :: s 1 :: :: s n γ Anc : m 1 {} m 2 {m 1 } m 3 {m 2, m 3 } m 4 {m 3 }.

43 Certification : concretisation examples γ Anc : (NameMethod (NameMethod)) (State + ) γ Anc (Anc) = { st 1 :: :: st n h i, m i, pc i, l i, s i, sf i {st 1,..., st n } m sf i, m Anc(m i ) } γ MutRecR : (NameMethod) (State + ) γ MutRecR (MutRecR) = h i, m i, pc i, l i, s i, sf i {st 1,..., st n } st 1 :: :: st n m i MutRecR m i sf i and methods in sf i are distinct

44 Certification : soundness lemmas For all variable X {Anc, MutRecR, LoopCall, Pred}, the corresponding system is proved correct Lemma Proof: P γ(x) prove the lattice structure of the underlying domain prove the monotony of γ X a classic subject reduction lemma: for any trace t 1 P, if t 1 γ X (X) and t 1 t 2, then t 2 γ X (X)

45 Certification : memory bounded theorem If the result of the analysis is false then there exists a bound on the number of memory allocations Theorem : memory bounded analysis soundness Unbounded(P) = false Max new, t P, t new < Max new Difficult proof with counting arguments, permutation of summation operators

46 Computing the analysis result The result of the analysis is computed by constraint iteration m 1 {} m 2 {} m 1 m 3 {} m 4 {} m2 m3 m4

47 Computing the analysis result The result of the analysis is computed by constraint iteration m 1 {} m 2 {m 1, m 3 } m 1 m 3 {m 2 } m 4 {m 3 } m2 m3 m4

48 Computing the analysis result The result of the analysis is computed by constraint iteration m 1 {} m 2 {m 1, m 2, m 3 } m 1 m 3 {m 1, m 2, m 3 } m 4 {m 1, m 2, m 3 } m2 m3 m4

49 Computing the analysis result The result of the analysis is computed by constraint iteration m 1 {} m 2 {m 1, m 2, m 3 } m 1 m 3 {m 1, m 2, m 3 } m 4 {m 1, m 2, m 3 } Termination : ascending chain condition on lattices m2 m3 m4

50 Computing the analysis result The result of the analysis is computed by constraint iteration m 1 {} m 2 {m 1, m 2, m 3 } m 1 m 3 {m 1, m 2, m 3 } m 4 {m 1, m 2, m 3 } Termination : ascending chain condition on lattices m2 m3 m4 these lattices are constructed by composition of lattice functors defined in a previous work [Esop 04]

51 Computing the analysis result The result of the analysis is computed by constraint iteration m 1 {} m 2 {m 1, m 2, m 3 } m 1 m 3 {m 1, m 2, m 3 } m 4 {m 1, m 2, m 3 } Termination : ascending chain condition on lattices m2 m3 m4 these lattices are constructed by composition of lattice functors defined in a previous work [Esop 04] An analyser written in Caml is automatically extracted from the whole Coq correctness proof

52 Outline Introduction The analysed language The algorithm Certification Experimental results Conclusion

53 Experimental results Observation : let F : program program the function which replaces in a program all instructions instr by nop for all standard bytecode program p, the analysis computation time on p and F(p) are the same We use this observation to test the efficiency of our analyser with a random generator of bytecode programs. Two parameters method number number of line per method

54 Computation time (seconds) Fixed number of line per method Memory usage (megabytes) Fixed number of line per method 0 50 k Program size (LOCs) 100 k 0 50 k Program size (LOCs) 100 k Fixed number method Fixed number method Computation time (seconds) Memory usage (megabytes) Program size (LOCs) 50 k 0 Program size (LOCs) 50 k

55 Outline Introduction The analysed language The algorithm Certification Experimental results Conclusion

56 Conclusion Efficient algorithm : between 40 and 80 s to analyse lines of code memory optimisation of the analyser : some lattices could be implemented with more efficient data-structures Completely certified algorithm proved correct with respect to the program semantics extracted implementation Proof based on a generic framework easier to combine the analysis proof with other analyses we could improve this analysis with a previous control flow analysis [Esop 03] we plan to refine this analysis with a relational numeric abstraction A good test for the abstract interpretation framework proposed in [Esop 03] a completely different analyse with a good re-use of some of the previous proofs