Analisi e Verifica di Programmi Laboratorio di AVP Corso di Laurea in Informatica AA Tino Cortesi

Analisi e Verifica di Programmi 2 Analisi e Verifica Cosa Individuare proprietà interessanti dei nostri programmi: Valori prodotti, dipendenze, uso, terminazione Perché: Verifica, Debugging Type checking Verifica di asserzioni Ottimizzazioni: Compile time garbage collection Ottimizzazioni source-to-source Come Le proprietà non banali dei programmi sono indecidibili o computazionalmente molto costose (NP) Approssimazioni o condizioni sufficienti

Tino CortesiAnalisi e Verifica di Programmi 3 Limpatto degli errori run-time Il 50% degli attacchi alla sicurezza dei sistemi avviene tramite buffer overruns (Microsoft Security Bulletins MS02-065, MS etc. La maggior parte dei crash in sistemi embedded è dovuta a overflow di vario tipo.

Tino CortesiAnalisi e Verifica di Programmi 4 Guyana francese, 4 giugno 1996 Lancio di ARIANE 5 $600 miliardi di dollari bruciati per un errore del software: un dato a 64 bit in virgola mobile venne convertito in un intero a 16 bit con segno, questa operazione causò una trap del processore:il numero in virgola mobile era troppo grande per poter essere rappresentato con un intero a 16 bit. (autodistruzione a 39 secondi dal lancio)

Tino CortesiAnalisi e Verifica di Programmi 5 Marte, Mars Polar Lander si spegne il 3 dicembre 1999 per una variabile non inizializzata.

Tino CortesiAnalisi e Verifica di Programmi 6 Sillabo del corso Elementi di Teoria dei Reticoli Interpretazione Astratta Correttezza dellanalisi - Connessioni di Galois - Widening Applicazioni a problemi di sicurezza Applicazioni nellambito delle basi di dati Dataflow Analysis Liveness Analysis Reaching Definitions - Constant Folding - Available Expressions Basic Blocks - Value Numbering - Alias Analysis Loop Optimizations Model Checking Seminari di ricerca su temi di Analisi e Verifica di Programmi Progetto: realizzazione guidata di codice per unanalizzatore statico

Tino CortesiAnalisi e Verifica di Programmi 7 Bibliografia F.Nielson, H.R.Nielson, C. Hankin Principles of Static Analysis Springer Verlag, 2004 B. Berard et al. Systems and Software Verification Springer Verlag, 1999 B,A,Davey, H,A, Priestly; Introduction to Lattices and Orders, Cambridge, 2006 Altri testi utili: A. W. Appel, Modern Compiler Implementation in Java Cambridge Univ. Press, 1998 Steven Mucknick, Compiler Design Implementation Morgan Kaufmann Publ., 1997 Articoli su journals o proceedings di conferenze

Introduzione

Tino CortesiAnalisi e Verifica di Programmi 9 Analisi Metodo conoscitivo che procede dallindividuazione e dallo studio dei particolari Scomposizione di un tutto organico nelle sue parti

Tino CortesiAnalisi e Verifica di Programmi 10 Analisi Statica di Programmi Tecniche automatiche per inferire a tempo di compilazione informazione approssimata sul comportamento run-time dei programmi Applicazioni: Ottimizzazione di compilatori Verifica automatica dei programmi Certificazione - validazione del software Sicurezza

Tino CortesiAnalisi e Verifica di Programmi 11 Esempio Cosa voglio verificare: assenza di un certo tipo di errori run-time (es. overflow) Come posso astrarre i valori numerici: Intervalli - Poliedri (disuguaglianze lineari) Quale teoria posso usare: Interpretazione astratta

Tino CortesiAnalisi e Verifica di Programmi 12 Etichettatura input n; m:=2; while n>1 do m:= m * n; n:= n-1; output m; (1) input n; (2) m:=2; while (3) n>1 do (4) m:= m * n; (5) n:= n-1; (6) output m;

Tino CortesiAnalisi e Verifica di Programmi 13 Grafo di flusso (1) input n; (2) m:=2; while (3) n>1 do (4) m:= m * n; (5) n:= n-1; (6) output m; input n m:= 2 n > 1 m:= m*n n:= n-1 output m

Tino CortesiAnalisi e Verifica di Programmi 14 Possiamo inferire mediante analisi statica che al punto (6) il valore della variabile m sarà pari per qualsiasi valore di input n. Per fare questo lanalisi dovrà propagare parity information Possiamo assegnare ad ogni variabile uno dei tre valori: Pariil valore è sicuramente pari Dispari il valore è sicuramente dispari Non_Soil valore può essere pari oppure dispari input n m:= 2 n > 1 m:= m*n n:= n-1 output m

Tino CortesiAnalisi e Verifica di Programmi 15 (1) input n; (2) m:= 2; while (3) n>1 do (4) m:= m * n; (5) n:= n - 1; (6) output m; (1) n Non_So m Non_So (2) n Non_So m Non_So (3) n Non_So m Pari (4) n Non_So m Pari (5) n Non_So m Pari (6) n Non_So m Pari

Tino CortesiAnalisi e Verifica di Programmi 16 Questo programma, dato un intero positivo n, calcola il doppio del fattoriale: 2 * (n!) n=1 … loutput è 2 n=2 … loutput è 4 n=3 … loutput è 12 n=4 … loutput è 48 pari! (1) input n; (2) m:= 2; while (3) n>1 do (4) m:= m * n; (5) n:= n - 1; (6) output m;

Tino CortesiAnalisi e Verifica di Programmi 17 Questo programma, dato un intero positivo n, calcola il fattoriale: n! In questo caso lanalisi precedente non restituisce nessuna informazione utile sulla parità di m. Questo è corretto (per n=1…) Ma nemmeno se restringiamo linput a n pari e n>1 lanalisi è precisa: in (3) sia n che m sono Non_So. (1) input n; (2) m:= 1; while (3) n>1 do (4) m:= m * n; (5) n:= n - 1; (6) output m;

Tino CortesiAnalisi e Verifica di Programmi 18 Precisione e Correttezza Questa perdita di precisione è una caratteristica comune delle tecniche di analisi statica La maggior parte delle proprietà sui programmi che si vogliono inferire sono indecidibili (o NP-complete), quindi non possiamo pensare di inferirle con precisione (ed in tempi ragionevoli) Dobbiamo assicurarci che il risultato dellanalisi sia in ogni caso corretto: Se lanalisi dice SI allora sicuramente la proprietà è verificata Se lanalisi dice NO allora può darsi che la proprietà non sia verificata

Tino CortesiAnalisi e Verifica di Programmi 19 Esempio Sappiamo che il problema della terminazione è indecidibile (halting problem) programmi programmi che terminano

Tino CortesiAnalisi e Verifica di Programmi 20 programmi programmi che sicuramente terminano programmi che terminano programmi che potrebbero terminare

Tino CortesiAnalisi e Verifica di Programmi 21 Precisione e Correttezza Unanalisi di terminazione può essere quindi di due tipi: Definite SIil programma sicuramente termina NOil programma potrebbe non terminare Possible SIil programma può terminare NOil programma sicuramente non termina

Tino CortesiAnalisi e Verifica di Programmi 22 Precisione e Correttezza Le tecniche di analisi che introdurremo si dicono semantics-based. Questo significa che linformazione ottenuta dallanalisi può essere dimostrata corretta rispetto alla semantica del linguaggio di programmazione

Tino CortesiAnalisi e Verifica di Programmi 23 Compilatori ottimizzanti Un compilatore ottimizzante trasforma un programma per migliorare la sua efficienza senza modificarne loutput. Trasformazioni che migliorano lefficienza: Allocazione dei registri Eliminazione delle sotto-espressioni comuni: se una espressione viene calcolata più di una volta, elimina le ripetizioni Eliminazione di dead-code: cancella una computazione il cui risultato non viene mai usato Constant folding: se gli operandi di unespressione sono costanti, il calcolo può essere fatto a tempo di compilazione.

Tino CortesiAnalisi e Verifica di Programmi 24 Escape Analysis Consideriamo queste due procedure in C: typedef int A[10000]; typedef A* B; void esegui1(){ int i; B b; b = (A*) malloc(sizeof(A)); for (i=0; i<100; i++) (*b)[i]=0; free(b); } void esegui2(){ int i; A a; for (i=0; i<100; i++) a[i]=0; }

Tino CortesiAnalisi e Verifica di Programmi 25 typedef int A[10000]; typedef A* B; void esegui1(){ int i; B b; b = (A*) malloc(sizeof(A)); for (i=0; i<100; i++) (*b)[i]=0; free(b); } B b int i ambiente stack memoria heap 0 Larray viene allocato nello heap e poi eliminato...

Tino CortesiAnalisi e Verifica di Programmi 26 A a int i ambiente stack memoria heap typedef int A[10000]; void esegui2(){ int i; A a; for (i=0; i<100; i++) a[i]=0; } Larray viene allocato nello stack e poi eliminato... 0

Tino CortesiAnalisi e Verifica di Programmi 27 allocare nello heap costa... for (i=0; i< ; i++) esegui1(); // circa 90 sec for (i=0; i< ; i++) esegui2();// circa 35 sec I programmi sembrano uguali, ma lallocazione nello heap fa sì che il primo sia tre volte più lento del secondo... Se riesco a predire che una variabile dinamica non esce dalla procedura dovè introdotta, posso sostituirla con una variabile locale.

Tino CortesiAnalisi e Verifica di Programmi 28 Esiste il compilatore ottimo? Definiamo fully optimizing compiler un compilatore che trasforma un programma P nel programma Opt(P) che è il più piccolo programma con lo stesso output di P. Dato un programma Q che non produce nessun output e non termina, Opt(Q) è facile da trovare: è il programma L1: goto L1; Supponiamo di avere un fully optimizing compiler. Potremmo usarlo per risolvere il problema della terminazione: per vedere se esiste un input per il quale P termina, basta vedere se Opt(P) è il programma L1: goto L1; Ma sappiamo che il problema della terminazione è indecidibile, ovvero che non esiste nessun algoritmo che lo risolve. Quindi non può esistere nemmeno un fully optimizing compiler.

Tino CortesiAnalisi e Verifica di Programmi 29 Ottimizzazione del codice Control-Flow Analysis Analisi Trasformazioni Idea: anziché chiedere al programmatore di preoccuparsi dellefficienza del programma, si può demandare a un compilatore ottimizzanti la trasformazione di un codice inefficiente in uno (equivalente) con performances migliori

Tino CortesiAnalisi e Verifica di Programmi 30 Trasformazioni ottimizzanti Le trasformazioni che un compilatore ottimizzante può operare seguono principalmente la seguente metodologia: Analisi: attraversa il grafo di flusso del programma e raccogli informazioni su cosa può succedere a tempo si esecuzione Trasformazioni: modifica il programma per renderlo in qualche modo più veloce. Linformazione ottenuta dallanalisi garantisce che il risultato del nuovo programma è uguale a quello del programma originario

Tino CortesiAnalisi e Verifica di Programmi 31 Tecniche di Analisi Statica Per definire unanalisi statica dobbiamo preoccuparci di: Come specificarla Come implementarla efficientemente Come provarne la correttezza

Tino CortesiAnalisi e Verifica di Programmi 32 Principali tecniche Abstract Interpretation Valutazione Parziale Dataflow Analysis Control Flow Analysis Model Checking Type Systems