ISPRAS Safety Related Projects Alexey Khoroshilov [email protected] Institute for System Programming of the Russian Academy of Sciences Institute for System Programming of RAS Main Departments ● Compiler Technology ● Information Systems ● Software Engineering ● Model checking, analytical verification, static analysis ● Model-based testing technologies ● Requirements management, model driven development ● Industrial Partners ● Samsung, Hewlett Packard, Linux Foundation, Google, IBM, Intel, Vympelcom Linux Verification Center founded in 2005 ● OLVER Program ● Linux Standard Base Infrastructure Program ● Linux Driver Verification Program 3 Safety Related Projects ● Static Analysis of Source Code ● Dynamic Analysis ● Testing Technologies ● requirements based testing ● model based testing ● Requirements Engineering ● System Design and System Integration ● MASIW - AADL based environment for IMA System Design&Integration in IMA ARP-4754 Avionics System Development Process ARP-4761 DO-254 Hardware System System Virtual System Integration Design Integration Top Level Aircraft Requirements DO-178B ATA-XX Incremental Generate config tables: Model AADL-model - ARINC-653 systems refinement development - device drivers Architecture evaluation: - Validation - middleware - safety analysis - Optimization - AFDX network - resource allocation - Scheludability analysis - simulation mode - Simulation Virtual System Integration on Base of AADL-models MASIW Plugin Architecture Testing Technologies ● Requality - requirements based testing development ● UniTESK – model-based testing technology ● T2C – normal quality tests with requirements traceability ● API Sanity Autotest – automatically generated sanity tests for API Test Suites ● Floating-point Mathematics Test Suite ● ARINC-653 Compliance Test Suite ● Linux Standard Base Compliance Tests ● model-based tests ● T2C tests ● sanity tests Floating Point Mathematics Tests ARINC-653 & Linux Tests OLVER (Open Linux VERification) ● Analysis and formalization of LSB Core 3.1 requirements on Linux system interfaces ● Development of a specification-based open source Test Suite for LSB conformance and functional testing of Linux 11 Target System 12 OLVER Process 13 Requirements Elicitation ● Markup assertions while reading standard 14 OLVER Process 15 Template Generation ● Universal test assertions are produced ready to paste into the source code of the test. Each assertion has correct ID and comment ● pre/post conditions and errors are grouped separately 16 Specification Example 17 Test Oracles Automatic checking of output correctness System Test stimuli Under ? Test Test Specifications oracle 18 OLVER Process 19 Test Scenario Model Test Engine Test Scenario 20 OLVER Process 21 Test Reports (1) Expandable tree of all the assertions and overall statistics: assertion coverage for particular test run (covered/total) 22 Test Reports (2) Green color marks requirements that were checked by the test run 23 OLVER Results ● Open source test suite included into official LSB certification program ● LSB Infrastructure Program ● http://ispras.linuxfoundation.org 24 Dynamic Analysis ● KEDR – valgrind like framework for Linux kernel space analysis ● Data Race Detector for a ARINC-653 and POSIX compliant RTOS ● Research on couple of approaches to data race detection for Linux kernel space Static Analysis Key characteristics • Scope of analysis (kind of bugs) • False positives (false bugs reported) • False negatives (real bugs missed) • Resources required for analysis Static Analysis: Trade-Off Triangle False positives Time of analysis False negatives Static Analysis: Trade-Off Triangle False positives light-weight heavy-weight Time of analysis False negative Heavy-Weight Analysis Based on a picture from http://engineer.org.in Static Analysis vs Model Checking Static Analysis Model Checking potential bugs found SAFE UNSAFE UNKNOWN error trace Model Checking: Originally property to be checked expert Model Checker VERDICT: SAFE ERROR TRACE: program model of the UNSAFE init(); in C program UNKNOWN X = 0; open(); write(); do_write(); if (X == 0) assert() Model Checking: Inside ● Reachability problem entry point r b1 b1 a2 a2 a2 a2 b2 b2 b2 b2 b2 b2 b2 b2 error location Model Checking: Now ● BMC – Bounded Model Checking ● CEGAR – Counter-Example Guided Abstraction Refinement Bounded Model Checking ● finite unfolding of transition relation r b1 b1 a2 a2 a2 a2 b2 b2 b2 b2 b2 b2 b2 b2 Counter-Example Guided Abstraction Refinement The path The path is unfeasible is feasible 4. Model 3. Error trace UNSAFE refinement analysis new There is a path trace precision to error state 2. Model SAFE program 1. Abstraction in C checking model of the program http://sv-comp.sosy-lab.org SVCOMP'12 Results CEGAR CEGAR CEGAR BMC BMC BMC CEGAR CEGAR CEGAR Model Checking and Linux Kernel ● Reachability problem entry point r b1 b1 a2 a2 a2 a2 b2 b2 b2 b2 b2 b2 b2 b2 error location Verification Tools World int main(int argc,char* argv[]) { ... other_func(var); void other_func(int v) ... { ... } assert( x != NULL); } Device Driver World Callback interface procedures registration ret = pci_register_driver(&DAC960_pci_driver) No explicit calls to linking-level init module_init(DAC960_init_module); procedures module_exit(DAC960_cleanup_module); Pseudo-main generation int main(int argc,char* argv[]) { init_module() for(;;) { switch(*) { case 0: driver_probe(*,*,*);break; case 1: driver_open(*,*);break; ... } } exit_module(); } 41 Pseudo-main generation (2) ● Order limitation ● open() after probe(), but before remove() ● Implicit limitations ● read() only if open() succeed ● and it is specific for each class of drivers 42 Model Checking and Linux Kernel ● Reachability problem entry point r b1 b1 a2 a2 a2 a2 b2 b2 b2 b2 b2 b2 b2 b2 error location Rule Instrumentor mutex x; int x_locked = 0; int f(int y) int f(int y) { { assert(x_locked == 0); lock(x); x_locked = 1; ... ... assert(x_locked == 1); unlock(x); x_locked = 0; return y; return y; } } Aspect-Oriented Approach mutex x; Aspect: int f(int y) around: { call(int lock(mutex x) lock(x); { ... assert(x_locked == 0); unlock(x); x_locked = 1; return y; } } Rule Instrumentor mutex x; int x_locked = 0; int f(int y) int f(int y) { { assert(x_locked == 0); lock(x); x_locked = 1; ... ... assert(x_locked == 1); unlock(x); x_locked = 0; return y; return y; } } Rule Instrumentor: Implementation ● CIF – C Instrumentation Framework ● gcc-based aspect-oriented programming tool for C language ● available at forge.ispras.ru under GPLv3 Where we are ● Static analysis infrastructure ● Front-ends ● ldv-manager ● ldv-git ● ldv-online ldv-online ldv-online (2) Where we are ● Static analysis infrastructure ● Cluster framework ● Front-ends ● ldv-manager ● ldv-git ● ldv-online ● Results database ● Error trace visualizer ● Knowledge base ● Comparison framework Error Trace Visualizer Knowledge Base Bugs Found http://linuxtesting.org/results/ldv ● 50 patches already applied Berkeley BLAST Lazy Abstraction Software Verification Tool BLAST is a software model checker for C programs. It uses counterexample-driven automatic abstraction refinement to construct an abstract model which is model checked for safety properties. ISPRAS BLAST 2.6 Release Notes Speedup ranges from 8 times on small-sized programs to 30 times on medium-sized programs ● Logarithmic algorithm for useful-blocks (significantly speedup of trace analysis) ● Improved integration with SMT solvers ● efficient string concatenation ● caching of converted formulae ● optimization of CVC3 options for BLAST use cases ● Formulae normalization moved to solvers since solvers do it faster ● Alias analysis speedup ● must-aliases are handled separately and faster than may-aliases ● removed unnecessary debug prints from alias iteration (even a check for debug flag impacts performance significantly in hot places) ● BLAST-specific tuning of OCaml virtual machine options SVCOMP'12 Results CEGAR CEGAR CEGAR BMC BMC BMC CEGAR CEGAR CEGAR Thank you! Alexey Khoroshilov [email protected] Institute for System Programming of the Russian Academy of Sciences.