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

R R R R R R A A A A A A G G G C C C G G G E E E M M M E E E C C C B B B C C C 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; ...... unlock(x); assert(x_locked == 1); 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; ...... unlock(x); assert(x_locked == 1); 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

R R R R R R A A A A A A G G G C C C G G G E E E M M M E E E C C C B B B C C C Thank you!

Alexey Khoroshilov [email protected]

Institute for System Programming of the Russian Academy of Sciences