You are on page 1of 28

Model Checkers: Uma análise de ferramentas para a linguagem de programação C

TRABALHO DE GRADUAÇÃO

Pedro Montenegro (pmr@cin.ufpe.br) 2007.1

ROTEIRO

 

Contexto
Introdução Objetivos


    

Model Checking
Ferramentas para a linguagem C Análise das Ferramentas Estudo de Caso Conclusão Trabalhos Futuros

Contexto  Cooperação de pesquisa entre o CIn/UFPE e uma Empresa de São Paulo Sistema do complexo de metrô de Santiago no Chile Componente crítico do metrô  Controladora Geral de Portas (CGP) Casos de Uso  Função abre portas     Função fecha portas .

Introdução  Sistemas críticos necessitam de garantia de funcionamento perfeito Falhas podem levar a perdas financeiras ou de vidas humanas Um dos pontos fundamentais para garantir esse alto nível de qualidade é a análise formal de propriedades    Necessidade de suporte ferramental que automatize o processo de verificação .

as abordagens que utilizam. as vantagens e desvantagens Apontar a ferramenta que apresentou os melhores resultados para o contexto do trabalho   .Objetivos  Procurar Ferramentas Model Checkers para a linguagem de Programação C Análise das ferramentas mais utilizadas em relação as características.

Model Checking  Nos últimos anos as indústrias reconheceram os verificadores de modelos como uma ferramenta promissora para o desenvolvimento de sistemas  Provou ser uma tecnologia bem sucedida para verificar exigências  Técnica totalmente automática que analisa o espaço de estados finito de sistemas críticos  Verifica automaticamente a validade de propriedades acerca do comportamento de sistemas .

Model Checking  Para realizar a validação das propriedades de sistemas seguem-se três passos:  Modelagem  Especificação  Verificação .

Model Checking  Tipos de Propriedades  Segurança  Atingibilidade (Reachability)  Razoabilidade (Fairness)  Ausência de Deadlock  Vivacidade (Liveness)  Verificação de Modelos na prática  Problemas como a explosão de estados e especificação de propriedades  Estratégias .

Model Checking  Abordagens da técnica  Bounded Model Checking (BMC)  Abstração de predicados Usando um provador de teoremas Usando resolvente SAT  Migração de C para outro modelo .

Ferramentas  SLAM  Impulsionou o uso de verificação de modelos  Usado com sucesso em Device Drivers do Windows  O SLAM tem três componentes principais:  c2bp .executa a análise da atingibilidade de programas booleanos  newton .avalia um abstração booleana do programa  bebop .verifica a praticidade dos caminhos de erros  O SLAM usa o zapato como seu provador de teorema .

opt  Usa “Simplify” e “vampyre” como provadores de teorema .Ferramentas  BLAST  A abordagem é a mesma seguida no SLAM  Usa conceitos de abstração “preguiçosa”  Composto pelo spec.opt e pblast.

constrói um CFG do programa  Verificador de modelos .constrói um PDA do CFG e verifica se o PDA vai de encontro à propriedade de segurança .Ferramentas  MOPS  Ferramenta de análise estática  Abordagem baseada em CFG (gráfico do fluxo de controle)  Consiste em um “parser” e um verificador de modelos  Parser .

Se falhar. limitado por algum inteiro N. o usuário pode então fornecer um limite superior  Usada como ferramenta para encontrar erros e não provar a exatidão .  Na maioria dos casos CBMC pode determinar o limite superior N.Ferramentas  CBMC  Bounded Model Checker (verificador de modelos limitado)  Usa um resolvente SAT  Procura por um contra-exemplo.

Ferramentas    SATABS MAGIC / ComFoRT Resumo das ferramentas .

não suporta programas muito grandes .Análise de Ferramentas  SLAM  Potencialidades  Sucesso com Device Drivers  Suporta procedimentos recursivos  Limitações  Tratamento dos ponteiros – Abstrair de uma linguagem com ponteiros (C) a uma sem ponteiros (programas booleanos) é difícil  Foco no domínio da aplicação de Device Drivers  Parte de um produto comercial (SDV) da Microsoft  Atualmente.

Análise de Ferramentas  BLAST  Potencialidades  Usa a abstração sob demanda para reduzir o refinamento desnecessário da abstração – Economiza espaço e tempo  Atualmente. incluindo estruturas e procedimentos  Encontrou erros em diversos Drivers  Limitações  A versão atual não suporta ponteiros para função  Funções recursivas não são suportadas . diz suportar muitas construções sintáticas de C.

Análise de Ferramentas  MOPS  Potencialidades  Escalabilidade e eficiência por considerar somente o fluxo de controle e por ignorar a maioria do fluxo de dados  Habilidade em relatar somente um “trace” de erro para cada causa do erro – Reduz significativamente o número de erros que o programador tem que rever  Limitações  Precisão afetada por priorizar a escalabilidade e ignorar o fluxo de dados .

Análise de Ferramentas  CBMC  Potencialidades  A principal é o suporte a maioria das estruturas de C – Escalabilidade é um grande diferencial do CBMC  Usa um resolventes SAT  Interface amigável  Limitações  Não poder provar a ausência de erros na maioria dos casos reais  Por priorizar a escalabilidade. a precisão é comprometida .

Análise de Ferramentas  Três propriedades são consideradas:  Soundness  Completeness  Termination .

Análise de Ferramentas  Difícil apontar uma ferramenta que seja a melhor  Para cada situação uma ferramenta pode se encaixar melhor  Depende das características do código C do programa que se quer analisar  Da forma mais geral possível  BLAST .

Estudo de Caso    Análise das estruturas de C utilizadas no componente Ferramenta utilizada : CBMC Utilização da função assert  Verificação do estado que se encontra o programa e suas variáveis de controle depois da execução de uma função do componente  Problemas como comportamento indesejado  Determinar a alcançabilidade dos estados implementados no componente  Utilização de um plugin para o eclipse .

sendo que dois deles foram selecionados e relatados:  Um fluxo de uma operação de abrir e fechar portas com velocidade menor que 3Km/h  A verificação da alcançabilidade dos estados após a execução da função n vezes através do comando “while” (n limitado pela ferramenta) .Estudo de Caso  Variáveis do sistema precisaram ser declaradas no componente  Os nomes das variáveis foram trocados Uma função main foi declarada Velocidade máxima para abertura de portas  Documento de requisitos -> 6Km/h  Código -> 3Km/h    Foram verificados diversos fluxos do sistema.

Estudo de Caso  Exemplo do primeiro fluxo selecionado: .

um potencial problema foi encontrado  Foi escolhido um valor limite para as iterações do loop ao qual a função foi submetida  Valor que levasse em conta um grande número de análises e não levasse muito tempo para fazer as verificações  Problema com relação a atingibilidade do estado 6  Apesar de haver a possibilidade da variável ser alterada em outro componente do sistema  Análise foi feita somente em relação ao componente. considerando apenas as atribuições feitas pela função .Estudo de Caso  Com relação ao outro fluxo selecionado.

 Mostrando que o assert é sempre verdade. o estado 6 não foi alcançado.Estudo de Caso  A estratégia adotada foi a colocação do assert(CGP_informarProximoEstadoDireita_MEMORIA<=5). . ou seja. não assume o valor 6. e conseqüentemente. mostro que a variável de estado nunca assume valores maiores que 5.

Conclusão  Difícil apontar uma ferramenta que seja a melhor  Para cada situação uma ferramenta pode se encaixar melhor  Depende das características do código C do programa  Programas Seqüenciais  Extensões estão sendo desenvolvidas para programas concorrentes.  Algumas estruturas de C ainda não são suportadas  Tanto as ferramentas quanto as abordagens ainda têm muito a evoluir  Pesquisas estão sendo realizadas nesse sentido .

relatando os resultados obtidos.   Descrição do funcionamento das principais ferramentas. Análise das principais características das ferramentas mais utilizadas.  Descrição e análise das abordagens utilizadas pelas ferramentas para a linguagem C. as verificações realizadas e os problemas encontrados. .Contribuições  Procura de ferramentas Model Checkers para a linguagem C.  Aplicação prática de um Model Checker em um componente do metrô.

Trabalhos Futuros  Estudo mais aprofundado da utilização da lógica temporal nas ferramentas  Formulação de propriedades importantes na lógica temporal que um sistema crítico precisa validar  Submeter estas propriedades às diversas ferramentas e relatar os resultados  Estudo de possíveis melhorias das ferramentas  Abordagem utilizada  Implementação .