Combinazione di procedure di decisione nella verifica formale di software

Combinazione di procedure di decisione nella verifica formale di software Lorenzo Platania Tesi presentata per il conseguimento del titolo di Dottore in Ingegneria Informatica Relatore Correlatore Chiar. mo Prof. Alessandro Armando Dott. Jacopo Mantovani DIST Dipartimento di Informatica Sistemistica e Telematica Università degli Studi di Genova

Ringraziamenti Vorrei ringraziare tutte le persone che mi sono state vicine e mi hanno sopportato in tutti questi anni, in particolare i miei genitori. Ringrazio anche il mio relatore prof. Alessandro Armando ed il mio correlatore Jacopo Mantovani per aver reso possibile questo lavoro, per l aiuto e la pazienza mostratami.

Indice Ringraziamenti 1 Introduzione 1 2 Model Checking 4 2.1 Introduzione............................ 4 2.2 Elementi di logica proposizionale................ 5 2.3 Modello un sistema........................ 7 2.3.1 Strutture di Kripke.................... 7 2.3.2 Rappresentazione simbolica degli stati......... 8 2.4 Specifica delle proprietà di un sistema.............. 8 2.4.1 Logica temporale CT L.................. 10 2.5 Verifica del modello rispetto alle proprietà........... 13 2.6 Sistemi a stati infiniti e Model Checking............ 14 2.6.1 Bounded Model Checking................ 14 3 Cenni sulla combinazione di teorie 20 3.1 Procedure di decisione nel Model Checking........... 20 3.1.1 Risultati teorici sulla combinazione di teorie e decidibilità 21 4 Bounded Model Checking di programmi C 23 4.1 Definizioni e convenzioni..................... 23 4.2 Introduzione............................ 24 4.3 Trasformazioni preliminari.................... 25 4.4 Srotolamento dei cicli....................... 29 4.5 Single assignment form...................... 30 4.5.1 Rinomina delle variabili................. 30 4.5.2 Rimozione dei side effects................ 31 4.5.3 Operatori condizionali e side effects........... 34 4.6 Rimozione dei goto in avanti.................. 35 4.7 Generazione della formula.................... 35 I

4.8 Codifica e risoluzione della formula............... 38 5 Analisi sperimentale 40 5.1 Implementazione......................... 40 5.1.1 Formato dei programmi di input............. 41 5.1.2 Formato dell output................... 41 5.1.3 Uso di CVC-LITE.................... 41 5.2 Analisi sperimentale....................... 42 5.2.1 I benchmark........................ 42 6 Conclusioni 53 A 58 A.1 Istanza 3 di array init assign.................. 59 A.2 Formula C per array init assign3.c................ 59 A.3 Formula U per array init assign3.c................ 61 A.4 Formula P per array init assign3.c............... 61 A.5 Traccia d errore per array init assign3.c............. 62 II

Elenco delle figure 2.1 Esempio di BDT......................... 9 2.2 BDD per la formula (a b) (c d) con a < b < c < d.... 9 2.3 BDD per la formula (a b) (c d) con a < c < d < b.... 10 2.4 Struttura di Kripke........................ 11 2.5 Operatori CT L.......................... 13 2.6 Contatore modulo 2........................ 16 4.1 Sostituzione di continue con goto............... 25 4.2 Sostituzione di break con goto................. 26 4.3 Sostituzione di costrutti switch................. 27 4.4 Trasformazione di un costrutto for in while.......... 28 4.5 Trasformazione di un costrutto do in while.......... 28 4.6 Esempio di rinomina....................... 31 4.7 Espansione di chiamate a funzioni................ 33 4.8 Esempio di rimozione di forward goto.............. 36 5.1 Risultati degli esperimenti su Bubble Sort........... 44 5.2 Dimensioni delle formule generate dai due model checker con codifica degli interi a 32 bit durante gli esperimenti su Bubble Sort................................ 44 5.3 Risultati degli esperimenti su Selection Sort.......... 45 5.4 Risultati degli esperimenti su Insertion Sort.......... 46 5.5 Risultati degli esperimenti sull implementazione dell algoritmo Bellmann-Ford.......................... 47 5.6 Dimensioni delle formule generate per l algoritmo Bellmann-Ford 48 5.7 Risultati degli esperimenti su array init............. 49 5.8 Risultati degli esperimenti su array init assign......... 49 5.9 Risultati degli esperimenti su simple array inversion.c..... 50 5.10 Risultati degli esperimenti su array max.c........... 50 5.11 Risultati per successione di Fibonacci.............. 51 5.12 Risultati per somma dei primi n numeri............ 52 III

Capitolo 1 Introduzione Il software ha assunto, nelle ultime decine di anni, un importanza rilevante in molte aree della nostra società, quali, ad esempio quella medico-sanitaria, dei trasporti, delle telecomunicazioni e della produzione industriale. Di conseguenza, l affidabilità e la correttezza del software è un argomento di grande attualità. La storia è ormai ricca di esempi di difetti nel software che hanno portato a conseguenze tragiche. Tra gli esempi disponibili in letteratura possiamo citare il caso di Therac-25 [LT93], una macchina per l emissione di radiazioni a scopo terapeutico controllata dal computer. Vari errori presenti nel software di gestione, oltre che nell intero processo di sviluppo, hanno provocato, su alcuni pazienti, un overdose di radiazioni con effetti anche mortali. La presenza di errori all interno del software ha anche un notevole impatto economico sia per gli effetti causati, sia per le risorse allocate nel processo di rilevazione e correzione dei difetti. A titolo di esempio, citiamo uno studio, pubblicato nel maggio 2002, commissionato dal NIST (National Institute of Standards and Technology del governo degli Stati Uniti) [RTI02], in cui si stima che l economia americana trarrebbe un vantaggio economico pari a 59,5 miliardi di dollari se fosse possibile rilevare e correggere istantaneamente ogni errore presente nel software. La verifica di sistemi software è stata ed è tradizionalmente eseguita per mezzo di tecniche di testing. Nonostante queste si siano evolute e raffinate nel tempo, difficilmente potranno mai essere esaustive e garantire la correttezza dell intero sistema oggetto di verifica. Ciò è particolarmente vero quando l oggetto della verifica è un sistema complesso, in quanto esso può presentare comportamenti spesso non determinabili a priori. Per contro, le tecniche di verifica formale si occupano di considerare ogni possibile evoluzione del sistema, allontanando ogni dubbio circa l esistenza di errori non considerati. Tra queste ricordiamo la tecnica di Model Checking, inizialmente proposta 1

per la verifica automatica di sistemi a stati finiti quali, ad esempio, sistemi hardware. In particolare essa, quando usata in combinazione con i Binary Decision Diagram (BDD) [Bry86], ha permesso di verificare sistemi con un numero di stati superiore a 10 120. Un ulteriore evoluzione, anch essa inizialmente proposta per la verifica di componenti hardware, è rappresentata dal Bounded Model Checking (BMC), che riduce il problema di verifica a quello di stabilire la soddisfacibilità di una formula proposizionale. In esso, le possibili evoluzioni ed i requisiti del sistema vengono codificati con una formula proposizionale. Gli eventuali modelli della formula ottenuta corrispondono ad una violazione, da parte del sistema, di almeno uno dei requisiti specificati. Un estensione di questa tecnica, affinchè potesse essere usata, oltre che per l hardware, anche per la verifica di programmi C, è stata proposta in [CKY03, CKSY04]. La sua implementazione ha dato origine al model checker CBMC (C Bounded Model Checking). I risultati ottenuti con questa tecnica si sono rivelati molto positivi, come dimostrato dal fatto che con essa sono stati verificati un implementazione dell algoritmo per cifratura DES, il sistema anticollisione aerea TCAS (Traffic Alert and Collision Advoidance System) ed il µc/0s-ii, un kernel per micropocessore. In quest ultimo caso CBMC ha rilevato, in quasi 3000 linee di codice, un errore nel protocollo di locking che non era ancora noto. La tecnica implementata da CBMC presenta alcuni limiti: vi sono, infatti, diverse istanze di programmi per cui CBMC genera una formula di dimensioni troppo elevate da non poter essere decise in tempi e con risorse ragionevoli. Contributo della tesi Il contributo di questa tesi consiste nello sviluppo di una generalizzazione dell approccio di [CKY03] che tiene conto delle considerazioni fatte in precedenza. Tale generalizzazione sfrutta la disponibilità di efficaci procedure di decisione per verificare efficientemente un ampia classe di programmi. Abbiamo mostrato come la codifica in formule in teorie più ricche (come per esempio quella dell aritmetica lineare e quella degli array) porti alla generazione di formule più compatte, che quindi possono essere decise più velocemente. Abbiamo anche realizzato un prototipo, chiamato SMT-CBMC, che implementa tale approccio e che fa uso di CVC-LITE per stabilire la soddisfacibilità delle formule generate. L implementazione ha convalidato quanto considerato circa le dimensioni della codifica e circa l efficacia del nostro approccio. Gli esperimenti sono stati condotti su una selezione di programmi di uso comune, quali alcuni algoritmi d ordinamento ed un algoritmo per la 2

ricerca del percorso minimo tra due nodi in un grafo, e su alcuni programmi sintetici già adoperati come benchmark in letteratura Struttura del documento Nel capitolo 2 vengono presentati i fondamenti teorici su cui si basa questa tesi. In particolare, dopo aver introdotto alcuni concetti di base della logica proposizionale, descriviamo un formalismo per modellare il comportamento di alcune classi di sistemi ed un esempio di logica temporale adatta per descrivere le proprietà di un sistema. In seguito si descrivono i risultati teorici su cui è stata sviluppata la tecnica di Bounded Model Checking. Nel capitolo 3 vengono descritte le teorie dell aritmetica lineare, degli array e dei bit vector e vengono forniti alcuni cenni sulla combinazione di teorie. Nel capitolo 4 viene mostrato in cosa consiste la tecnica introdotta in [CKY03] per il Bounded Model Checking di programmi C. Inoltre si descrive come tale tecnica possa essere generalizzata, come la formula proposizionale ottenuta può essere codificata e quali sono le conseguenze del tipo di codifica usato. Nel capitolo 5 viene descritto il prototipo SMT-CBMC ed i benchmark su cui è stata valutata l efficacia dell approccio presentato in questa tesi. Vengono inoltre mostrati i risultati degli esperimenti condotti e confrontati con quelli ottenuti con il bounded model checker CBMC. 3

Capitolo 2 Model Checking In questo capitolo, dopo alcuni richiami teorici di logica proposizionale, spieghiamo in cosa consiste il Model Checking e descriviamo alcuni dei suoi limiti. Inoltre, introduciamo la tecnica di Bounded Model Checking, mostriamo sotto quali condizioni tali tecniche sono equivalenti, e come ridurre il problema di Bounded Model Checking al problema di soddisfacibilità di una formula proposizionale. 2.1 Introduzione La tecnica di model checking [EMCGP99] è comunemente usata per la verifica automatica di sistemi rispetto ad alcune proprietà specificate. Il processo di model checking può essere suddiviso nelle fasi di: 1. costruzione di un modello che rappresenti il sistema trascurando tutti i dettagli non significativi al fine della verifica. Spesso, i sistemi da verificare sono di tipo reattivo [MP95], ovvero sistemi che interagiscono con l ambiente esterno. Il comportamento di sistemi di questo tipo può essere ben descritto da sistemi stati-transizione, ovvero da grafi orientati in cui i nodi rappresentano i possibili stati del sistema (definiti dai valori assunti dalle variabili di stato del sistema stesso) e gli archi le transizioni da uno stato al suo successore; 2. specifica delle proprietà che si desidera il sistema soddisfi durante il suo evolvere nel tempo. Ciò può essere fatto per mezzo di una qualche logica temporale. 3. verifica del modello del sistema rispetto alle proprietà specificate. Essa consiste, in ultima analisi, in una ricerca esaustiva dello spazio degli 4

stati del sistema, al fine di determinare se le proprietà specificate sono verificate o meno all interno di tale spazio. Questa fase è totalmente automatizzata e richiede l intervento umano solo per l analisi del risultato. Nel caso in cui il sistema non soddisfi le specifiche, il processo di model checking mostra la sequenza di stati che porta il sistema a violare una proprietà. Tale sequenza è detta traccia. Dall analisi della traccia si possono ricavare informazioni utili per apportare le necessarie correzioni al sistema in oggetto. È anche possibile che il processo di model checking termini prima di aver completato la verifica del sistema, a causa di insufficienza di risorse per la computazione. In questo caso, l utilizzo di un modello più astratto che tralasci alcuni dettagli non essenziali, può rendere praticabile l utilizzo di procedure di model checking. Il processo di model checking presenta notevoli vantaggi sia rispetto a tecniche semi-formali come il testing, sia rispetto ad altre tecniche formali, quali il theorem proving o l abstract interpretation. Rispetto alle prime, infatti, il model checking garantisce la completa esplorazione dello spazio degli stati, difficilmente ottenibile durante il processo di testing. Rispetto alle seconde, invece, il model checking non richiede un frequente intervento umano nella fase di verifica e può fornire un esempio di come il sistema violi una qualche proprietà. Nel seguito del capitolo, dopo aver introdotto i concetti base della logica proposizionale, mostreremo in dettaglio le singole fasi del model checking. Parleremo inoltre di come è possibile applicare le procedure di Model Checking su sistemi a stati infiniti e, a tal proposito, analizzeremo la tecnica del Bounded Model Checking. 2.2 Elementi di logica proposizionale Sintassi Un linguaggio proposizionale L è costituito da un alfabeto e da una grammatica. L alfabeto, che definisce quali simboli possono essere usati all interno del linguaggio, è costituito da: un insieme L di lettere proposizionali p, q, r,..., dette variabili atomiche, atomi proposizionali o più semplicemente atomi un insieme di connettivi,,, un insieme di simboli ausiliari (, ) 5

La grammatica, che descrive come i simboli dell alfabeto possono essere combinati per ottenere formule accettabili (formule ben formate), è definita dalle regole: ogni p L è una formula e sono formule se A 1 e A 2 sono formule, sono formule anche (A 1 A 2 ), (A 1 A 2 ), ( A 1 ) nient altro è una formula Semantica La semantica della logica proposizionale è definita tramite la nozione di interpretazione. Un interpretazione è una funzione che assegna valori di verità ad atomi. Sulla base dei valori così assegnati e delle regole che seguono la definizione di interpretazione, è possibile stabilire il valore di verità di una qualsiasi formula proposizionale. Definizione 2.1 (Valore di verità) Un valore di verità è un elemento dell insieme D := T rue, F alse Quando non vi sarà ambiguità, indicheremo i valori T rue e F alse rispettivamente con i simboli e, già utilizzati nel definire la sintassi di un linguaggio proposizionale. Avremo, quindi, che D :=,. Definizione 2.2 (Interpretazione) Sia dato l insieme L degli atomi proposizionali. Un interpretazione I è una funzione da L nel dominio, ovvero I : L D. In altre parole, la funzione d interpretazione assegna un valore di verità ad ogni membro di un insieme di atomi proposizionali. Il concetto di interpretazione può essere esteso induttivamente anche ai casi di formule con connettivi logici. Siano ϕ e ψ formule proposizionali. Allora: I( ) =, I( ) = ; I(ϕ ψ) = se e solo se I(ϕ) = e I(ψ) = ; I(ϕ ψ) = se e solo se I(ϕ) = o I(ψ) = ; I( ϕ) = se e solo se I(ϕ) = ; 6

Se per una formula ϕ ed un interpretazione I si ha I(ϕ) = (rispettivamente, I(ϕ) = ), diciamo che ϕ è vera (falsa) in I e denotiamo ciò con I = ϕ (I = ψ). Riassumendo, un interpretazione I lega ogni formula ϕ ad un valore di verità. Informalmente, con valore di una formula denotiamo il valore di verità cui essa è legata. Se una formula ϕ è vera in un interpretazione I, allora diciamo che I soddisfa ϕ o, analogamente, ϕ è soddisfatta da I, o che I costituisce un modello per ϕ. Una formula ϕ è valida se e solo se è vera per ogni possibile interpretazione I. Gli operatori, e, comunemente usati, sono stati tralasciati per semplicità. Essi sono comunque esprimibili per mezzo degli operatori,, tramite le seguenti equivalenze: ϕ ψ = ϕ ψ ϕ ψ = ( ϕ ψ) ( ψ ϕ) ϕ ψ = ( ϕ ψ) ( ψ ϕ) 2.3 Modello un sistema Il primo passo da compiere, nel processo di Model Checking, è la realizzazione di un modello del sistema da analizzare. Il livello di dettaglio del modello dovrà essere sufficiente a cogliere tutti gli aspetti rilevanti del sistema, tralasciandone, al tempo stesso, le caratteristiche non significative, in modo da non rendere più complesso del necessario il processo di verifica. 2.3.1 Strutture di Kripke Consideriamo sistemi di tipo reattivo, ovvero dei sistemi in grado di interagire con il loro ambiente e che evolvono indefinitamente nel tempo. Sistemi di questo tipo possono essere ben modellati attraverso un tipo di grafo statotransizione detto struttura di Kripke. Definizione 2.3 (Struttura di Kripke) Sia AP un insieme di proposizioni atomiche. Una struttura di Kripke M definita su AP è una tupla M = (S, In, R, L) dove 1. S è un insieme finito non vuoto detto insieme degli stati di M. 2. In S è un insieme non vuoto di stati detto insieme degli stati iniziali di M. 3. R S S è una relazione di transizione totale, ovvero, per ogni stato s S esiste un s S tale che R(s, s ). 7

4. L : S 2 AP è una funzione che etichetta ogni stato con l insieme di proposizioni atomiche che sono vere in quello stato. Siano V = v 1,..., v n le variabili del sistema considerato. Uno stato del sistema s è dato dalla valutazione delle variabili v i (i = 1,..., n) in s, ovvero, uno stato è una valutazione s : V D, dove D è il dominio dei valori che possono essere assunti dalle variabili. Un percorso π in M è una sequenza infinita di stati s 0 s 1 s 2... tale che, per ogni i 0, valga la relazione R(s i, s i+1 ). Nel caso in cui uno stato s non abbia successore, possiamo estendere la relazione R in modo che sia vera R(s, s). 2.3.2 Rappresentazione simbolica degli stati Le strutture di Kripke sono rappresentabili con formule proposizionali negli atomi di AP. Poichè la rappresentazione di un sistema dai molti stati tende ad essere di grandi dimensioni, mostriamo un metodo per mantenerla compatta. Ogni formula proposizionale booleana può essere rappresentata in maniera efficace, e generalmente compatta, per mezzo di una particolare struttura dati che prende il nome di Binary Decision Diagram (BDD) [Bry86]. Le caratteristiche citate per i BDD vengono messe in evidenza dal confronto con un altra struttura dati, i Binary Decision Tree (BDT). Un BDT è un albero binario in cui ogni nodo è associato ad una variabile ed ogni arco uscente è associato ad un valore di verità. Per determinare il valore di verità della formula rappresentata da un BDT, in presenza di un assegnamento delle variabili, è sufficiente attraversare l albero a partire dalla radice: dopo aver visitato un nodo, si percorre l arco corrispondente al valore assegnato alla variabile associata ad esso, ripetendo l operazione fino ad incontrare un nodo foglia (esempio in figura 2.1). Un BDD tenta di eliminare le ridondanze presenti nel BDT, combinando sotto-alberi isomorfi in un unico albero ed eliminando i nodi i cui sotto-alberi sono isomorfi (esempio in figura 2.2). Il processo che porta a conoscere il valore di verità di una formula rappresentata da un BDD è del tutto analogo a quello per i BDT, ma può richiedere meno iterazioni. È bene notare che l efficienza di un BDD nel rappresentare una formula proposizionale dipende fortemente dall ordinamento scelto per le variabili (si veda figura 2.3). 2.4 Specifica delle proprietà di un sistema Spesso, le proprietà che si desiderano soddisfatte da un sistema sono legate al concetto di tempo. Per esempio si può desiderare che una proprietà sia verificata per tutte le configurazioni del sistema che seguono il presentarsi di 8

a 0 1 b b 0 1 0 1 c c c c 0 1 0 1 0 1 0 1 d d d d d d d d 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 1 1 1 1 Figura 2.1: BDT per la formula (a b) (c d) con a < b < c < d a 1 0 b 0 c 1 1 0 d 1 0 1 Figura 2.2: BDD per la formula (a b) (c d) con a < b < c < d 9

a 0 1 c 1 0 c 1 d 0 d 0 0 1 b 1 0 1 0 1 Figura 2.3: BDD per la formula (a b) (c d) con a < c < d < b un qualche stato. Per esprimere relazioni temporali tra stati si può fare uso di un qualche tipo di logica temporale. Nel seguito descriviamo, a titolo di esempio, la logica temporale CT L (Computational Tree Logic) descritta in [EMCGP99]. 2.4.1 Logica temporale CT L L uso della logica temporale nel model checking è stato introdotto all inizio degli anni 80 in [CE82]. Questo tipo di logica permette di descrivere come la sequenza di stati evolve senza menzionare esplicitamente il tempo, ma facendo riferimento alla sequenza con cui essi si presentano. La logica CT L rappresenta un valido esempio di logica temporale, grazie alla sua potenza espressiva. Essa permette di descrivere proprietà temporali riferendosi ad un albero di computazione, ovvero ad un albero ottenuto srotolando, a partire da uno stato scelto come radice, la struttura di Kripke del sistema in oggetto. In pratica, l albero di computazione rappresenta tutte le possibili evoluzioni del sistema a partire dallo stato scelto come iniziale (vedi esempio in figura 2.4). All interno della logica CT L abbiamo due tipi di formule: 1. formule di stato, che fanno riferimento ad un determinato stato 2. formule di percorso, che fanno riferimento ad un dato percorso 10

a a b c b c a c c Figura 2.4: Struttura di Kripke e corrispondente albero di computazione Sia AP un insieme di atomi proposizionali. La sintassi delle formule CT L è così definita: se p AP allora p è una formula di stato se f e g sono formule di stato, allora f, f g e f g sono formule di stato se f è una formula di percorso, allora E f e A f sono formule di stato se f è una formula di stato, allora f è anche una formula di percorso se f e g sono formule di percorso, allora f, f g, f g, X f, F f, G f, f E g e f E g sono formule di percorso se f e g sono formule di stato, allora X f, F f, G f, f U g ed f R g sono formule di percorso. In altre parole, ogni operatore temporale deve essere immediatamente preceduto da un quantificatore di percorso. Le formule CT L fanno uso di quantificatori di percorso e di operatori temporali. I primi sono usati per associare le proprietà a tutti o ad alcuni dei percorsi che partono dal nodo considerato. In particolare, i quantificatori di percorso sono: A: per ogni percorso; E: esiste un percorso. Gli operatori temporali, invece, descrivono proprietà temporali di un singolo percorso. In particolare, siano φ e ψ due formule: Xφ richiede che φ valga nello stato immediatamente successivo al corrente 11

Fφ richiede che φ valga in un qualche stato futuro del percorso considerato Gφ richiede che φ valga in ogni stato del percorso considerato φuψ richiede che ψ valga in qualche stato del percorso e che φ sia verificata in ogni stato precedente φrψ richiede che ψ valga fino allo stato in cui vale φ. Comunque, φ potrebbe non essere mai verificata. È possibile definire la semantica della logica temporale CT L facendo riferimento ad una generica struttura di Kripke M = (S, In, R, L) (si veda paragrafo 2.3.1) dove, ricordiamo, S è l insieme degli stati, R S S è la relazione di transizione ed L : S 2 AP è una funzione che etichetta ogni stato con l insieme di proposizioni atomiche vere in quello stato. Un percorso π in M è una sequenza di stati s 0, s 1,..., tale che, per ogni i 0, (s i, s i+1 ) R. Con π i denotiamo il suffisso di π che comincia da s i. Se f è una formula di stato, con M, s = f intendiamo dire che f è vera nello stato s della struttura di Kripke M. Analogamente, se f è una formula di percorso, M, π = f indica che f è vera lungo il percorso π della struttura di Kripke M. Assumendo che f 1 ed f 2 siano formule di stato e g 1 e g 2 siano formule di percorso, la relazione = è definita per induzione come segue: M, s = p p L(s) M, s = f 1 M, s f 1 M, s = f 1 f 2 M, s = f 1 o M, s = f 2 M, s = f 1 f 2 M, s = f 1 e M, s = f 2 M, s = E g 1 esiste un percorso π che parte da s tale che M, π = g 1 M, s = A g 1 per ogni percorso π che parte da s M, π = g 1 M, π = f 1 s è il primo stato di π e M, s = f 1 M, π = g 1 M, π g 1 M, π = g 1 g 2 M, π = g 1 om, π = g 2 M, s = g 1 g 2 M, π = g 1 e M, π = g 2 M, π = X g 1 M, π 1 = g 1 M, π = F g 1 esiste un k 0 tale che M, π k = g 1 M, π = G g 1 per ogni i 0, M, π i = g 1 12

M, π = g 1 U g 2 esiste un k 0 tale che M, π k = g 2 e per ogni 0 j k, M, π j = g 1 M, π = g 1 R g 2 per ogni 0 j, se per ogni i jm, π i g 1 allora M, π j = g 2 g g g g M, s 0 =EF g M, s 0 =AF g g g g g g g g g g g M, s 0 =EG g M, s 0 =AG g Figura 2.5: Esempi sul significato di alcuni operatori CT L 2.5 Verifica del modello rispetto alle proprietà Data una struttura di Kripke M = (S, In, R, L), che rappresenta un sistema a stati finiti, e una formula di logica temporale f, che esprime una qualche specifica desiderata, il problema del model checking consiste nel trovare tutti gli stati in S che soddisfano f, ovvero s S M, s f Un sistema soddisfa la specifica f se tutti i suoi stati iniziali sono in tale insieme. 13

2.6 Sistemi a stati infiniti e Model Checking Quando il sistema da verificare è, per esempio, un circuito elettronico, l ipotesi di finitezza dello spazio degli stati risulta essere soddisfatta grazie ad aspetti fisici del sistema: il numero di componenti del circuito e finito, ed è quindi sufficiente un numero finito di atomi proposizionali per modellare il loro comportamento. Tale ipotesi è fondamentale nel determinare l utilizzabilità pratica del model checking in quanto ne garantisce la terminazione. Il processo di model checking, infatti, può richiedere l esplorazione di tutti gli stati del sistema, al fine di determinare se una data proprietà è soddisfatta da esso o no. Spesso, però, i sistemi considerati non possiedono un numero di stati finito. È questo il caso tipico dei sistemi software in cui, ad esempio, è frequente trovare variabili che possono assumere valori in un dominio infinito e cicli la cui terminazione non è garantita. Per poter applicare anche in questi casi le procedure di model checking, sono state realizzate delle tecniche di modellamento del sistema che rendono praticabile l approccio fin qui visto. Tra queste possiamo ricordare l astrazione ed il bounded model checking. 2.6.1 Bounded Model Checking L utilizzo della rappresentazione simbolica dei sistemi ha permesso di poter applicare il Model Checking a sistemi di dimensioni maggiori rispetto a quanto poteva essere fatto utilizzando una rappresentazione esplicita. L uso dei BDD ha invece permesso una più agile manipolazione delle formule logiche che rappresentano il sistema, nonostante questo approccio possa ancora soffrire del problema dell esplosione dello spazio degli stati. Il Bounded Model Checking [BCCZ99], in un certo senso, rappresenta un ulteriore evoluzione delle tecniche di Model Checking. Esso infatti, grazie all efficacia delle procedure di decisione per formule proposizionali, generalmente fornisce velocemente un controesempio di lunghezza minima e, rispetto ai metodi basati sui BDD, usa meno risorse e le sue prestazioni non dipendono dall ordinamento scelto per le variabili: trovare l ordinamento ottimo per ottenere il BDD più piccolo possibile è infatti un problema NP completo. Nel bounded model checking vengono considerati percorsi di lunghezza prefissata k, ovvero si verifica se una proprietà è soddisfatta da un sistema per sequenze di stati di lunghezza non superiore a k. Per questa ragione il Bounded Model Checking risulta più versatile per la ricerca di errori piuttosto che per la verifica. Infatti, considerando percorsi di lunghezza k, non è possibile affermare nulla su quel che può accadere nelle successive evoluzioni del sistema. Ciò nonostante, quando la lunghezza dei percorsi considerati supera il diametro dello spazio degli stati, si può concludere che la proprietà rispetto alla quale 14

abiamo verificato il sistema è garantita essere soddisfatta. Sfortunatamente, nel caso di sistemi a stati infiniti, tale diametro è anch esso infinito. In questi casi è in generale possibile garantire il rispetto di una proprietà solo per percorsi di lunghezza finita. Esempio di Bounded Model Checking per un contatore modulo quattro Mostriamo ora un esempio di bounded model checking tratto da [BCCZ99]. Consideriamo il contatore a due bit la cui struttura di Kripke è mostrata in figura 2.6. Ognuno dei quattro stati è descritto dai valori dei due atomi proposizionali s(1) ed s(0) che denotano, rispettivamente, il bit più significativo e quello meno significativo. Lo stato iniziale è caratterizzato dal valore (00) del contatore, ed è descritto dalla formula I definita come ( s(1) s(0)). Sia s lo stato attuale ed s il suo successivo. La relazione di transizione T (s, s ) deve descrivere l incremento del contatore ad ogni passo. Definiamo inc(s, s ) come (s (0) s(0)) (s (1) (s(0) s(1))) e T (s, s ) come inc(s, s ) ((s(0) s(1)) (s (0) s (1))). Si noti che il sistema così descritto presenta un errore che rende possibile la transizione dallo stato (10) allo stato (10) stesso. Supponiamo di richiedere che il sistema raggiunga, prima o poi, lo stato (11). Questa proprietà può essere descritta in logica temporale tramite la formula AF(q), con q = (s(0) s(1)) la quale richiede che, in ogni percorso d esecuzione, valga q := s(0) s(1). Equivalentemente, possiamo cercare un percorso nel quale sia vera p := ( s(0) s(1)), concetto espresso dalla formula EG(p), ovvero cercare un controesempio della proprietà che si desidera soddisfatta dal sistema in esame. Come è tipico fare nel Bounded Model Checking, anzichè cercare un qualsiasi percorso nel quale sia soddisfatta EG(p), concentriamo l analisi su percorsi di lunghezza k, ovvero percorsi con k +1 stati. Considerando k = 2, imponiamo che i k +1 stati s 0, s 1, s 2 costituiscano un percorso valido che parte dallo stato iniziale. Facciamo ciò attraverso la formula [[M]] 2 := I T (s 0, s 1 ) T (s 1, s 2 ) nella quale abbiamo descritto lo stato iniziale ed espresso la relazione di transizione per i due passi considerati. Inoltre, dobbiamo imporre che il sistema abbia un ciclo che porta dallo stato s 2 ad un qualsiasi stato del sistema 1. Introduciamo quindi la formula logica L 2 := T (s 2, s 0 ) T (s 2, s 1 ) T (s 2, s 2 ). Infine richiediamo che la proprietà p sia vera in ogni stato del percorso considerato, introducendo la formula [[Gp]] 2 := L 2 p(s 0 ) p(s 1 ) p(s 2 ). Il risultato del modellamento del sistema è dato dalla formula [[M]] 2 [[Gp]] 2, che è sod- 1 È necessario imporre ciò affinchè i percorsi considerati siano di lunghezza infinita, come richiesto dalla tecnica di Model Checking. Ulteriori spiegazioni verranno date nel seguito del capitolo 15