Model Checkers: Uma análise de ferramentas para a linguagem de programação C TRABALHO DE GRADUAÇÃO

1. Model Checkers: Uma análise deferramentas para a linguagem deprogramação CTRABALHO DE GRADUAÇÃO Pedro Montenegro (pmr@cin.ufpe.br) 2007.1

2. ROTEIRO • Contexto • Introdução • Objetivos • Model Checking • Ferramentas para a linguagem C • Análise das Ferramentas • Estudo de Caso • Conclusão • Trabalhos Futuros

3. 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

4. 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

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

6. 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

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

8. 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

9. 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

10. 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 - avalia um abstração booleana do programa • bebop - executa a análise da atingibilidade de programas booleanos • newton - verifica a praticidade dos caminhos de erros • O SLAM usa o zapato como seu provador de teorema

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

12. 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 - 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

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

14. Ferramentas • SATABS • MAGIC / ComFoRT • Resumo das ferramentas

15. 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, não suporta programas muito grandes

16. 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, diz suportar muitas construções sintáticas de C, 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

17. 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

18. 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

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

20. 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

21. 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

22. 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, 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)

23. Estudo de Caso • Exemplo do primeiro fluxo selecionado:

24. Estudo de Caso • Com relação ao outro 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

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

26. 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

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

28. 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