Reducing Time and Efforts When Verifying Large Software Systems with - - PowerPoint PPT Presentation

reducing time and efforts when verifying large software
SMART_READER_LITE
LIVE PREVIEW

Reducing Time and Efforts When Verifying Large Software Systems with - - PowerPoint PPT Presentation

Reducing Time and Efforts When Verifying Large Software Systems with Klever Ilia Zakharov Ivannikov Institute For System Programming of RAS ilja.zakharov@ispras.ru Klever Verification Framework Intended for finding bugs in large software


slide-1
SLIDE 1

Reducing Time and Efforts When Verifying Large Software Systems with Klever

Ilia Zakharov

Ivannikov Institute For System Programming of RAS ilja.zakharov@ispras.ru

slide-2
SLIDE 2

Klever Verification Framework

Intended for finding bugs in large software systems using existing software verification tools

  • C programs
  • GNU C, Microsoft C
  • x86, ARM
  • > 200 KLOC
  • Requirements supported by software verification tools used as backends
  • Memory safety
  • Data races
  • API usage
  • Deliver both results and a program-adapted tool
  • Coverage reports, error traces and results of bugs triage
  • A tool to check regressions or reproduce results

2

slide-3
SLIDE 3

Workflow

3

  • Implement program-specific

parts in the framework

  • Prepare models and

specifications Development

  • Find bug
  • Deliver the tool and results

Verification

slide-4
SLIDE 4

Klever Verification Framework

4

Program Decomposition Environment Modeling Requirements Modelling Verification Results Assessment Source Code Bugs

  • r

Proofs

slide-5
SLIDE 5

Source Code Preparation

5

slide-6
SLIDE 6

Goals

  • Limit scope to specific components,

source code versions, architectures

  • Prepare requirements
  • Plan development stages
  • Find bugs or prove correctness
  • Deliver results or a tool

6

slide-7
SLIDE 7

Prepare Build Base

7

Executables Source Code Build System Clade and CIF Build Base

slide-8
SLIDE 8

Program Decomposition

8

slide-9
SLIDE 9

Program Decomposition

  • Reduce environment modelling efforts
  • Prevent timeouts
  • Get rid of unsupported code

9

Lib 1 Lib 2 Lib 3 Compone nt 1 Component 2 Fragment I Fragment II

slide-10
SLIDE 10

Extract Components as Fragments

10

  • 1. Determine logical components
  • With unique interface
  • With common interface
  • 2. Separate libraries
  • 3. Remove auxiliary or irrelevant parts
  • Debug
  • Tests
slide-11
SLIDE 11

Manual or Automatic Decomposition

  • Define fragments explicitly in

advance

  • Develop algorithms to decompose

the program using its build base

11

Core.c Driver2.c lib1.c lib.c Driver1.c Helper.c

4 3 10 2 3

slide-12
SLIDE 12

Provide Environment Models

12

slide-13
SLIDE 13

Kinds of Models

Kind of a Model External Functions Common Model Undefined functions that init/uninit resources and influence the control flow Requirement Model Specific API that should be properly used by the fragment Environment Model Functions that call entry points and influence these calls

13

Program Fragment Environment Model Requirement Model Common Model

slide-14
SLIDE 14

Environment Model

14

Lib Component Program

slide-15
SLIDE 15

Interraction Scenarios

15

Lib Component Program 1 1 2 2 3 4 4 5

slide-16
SLIDE 16

Intermediate Environment Model

16

moxa_open (failed) moxa_write moxa_open (success) moxa_close tty_alloc_driver (success) tty_alloc_driver (failed) tty_set_operations tty_register_driver (success) tty_register_driver (failed) put_tty_driver tty_unregister_driver Activate/deactivate

slide-17
SLIDE 17

Environment Model Generator

C Code Intermediate Environment Model Translator Environment Model Specifications Program Fragment Scenario Model Builders

17

slide-18
SLIDE 18

Environment Model Generator

18

Provide specifications as templates Manually develop environment model specifications Select auxiliary function models Adjust completeness

  • f the environment model

C Code Intermediate Environment Model Translator Environment Model Specifications Program Fragment Scenario Model Builders

slide-19
SLIDE 19

Provide Requirement Specifications

19

slide-20
SLIDE 20

Requirement Specification

int cnt = 0; int try_module_get(struct module * m) { ret = ldv_random_neg_int(); if (!ret) cnt++; return ret; } void module_put(struct module * m) { cnt--; } void ldv_check_final_state(void) { ldv_assert(cnt==0); }

20

slide-21
SLIDE 21

Requirement Specifications Development

  • 1. Support an empty requirement to measure the coverage
  • 2. Support memory safety and data race safety requirement

specifications

  • 3. Implement other requirement specifications
  • 4. Develop tests for requirement models

21

slide-22
SLIDE 22

Analyse Results

22

slide-23
SLIDE 23

Verification Results

  • Error traces (witnesses)
  • Coverage reports
  • Logs
  • Resource consumption statistics

23

slide-24
SLIDE 24

Use cases

24

Development

  • Uncovered entry points
  • Complicated code
  • Classify fails

Refinement

  • Marks and tags for errors and false positives
  • Regression tests

Verification

  • Find bugs
  • Prepare final marks and tags
slide-25
SLIDE 25

Evaluation

25

slide-26
SLIDE 26

Manual Effort at Verification of Linux Device Drivers and Subsystems

Stage Serial device drivers (20KLOC) All device drivers(4MLOC) Subsystems (1MLOC) Total Development of decomposition algorithms 0,25 man-months (100 LOC Python)

  • 0,25 man-months

(100 LOC Python) 0,5 man-months (200 LOC Python) Development of environment model builders 3 man-months (3 KLOC Python)

  • 0,5 man-months

(500 LOC Python) 3,5 man-months (3,5 KLOC Python) Development of environment model specifications 4,5 man-months (7 KLOC DSL) 5,5 man-months (10 KLOC DSL)

  • 10 man-months

(17 KLOC DSL) Development of requirement specifications 6 man-months (550 LOC DSL) 9 man-months (950 LOC DSL) 0,25 man-months (200 LOC DSL) 15,25 man-months (1500 LOC DSL) Total 13,75 man- months 14,5 man-months 1 man-month 29,25 man-months

26

slide-27
SLIDE 27

BusyBox Applets Verification

27

Stage Efforts Development of decomposition algorithms 0,25 man-months (100 LOC Python) Development of environment model builders 0 man-months

  • Development of

environment model specifications 0,25 man-months (200 LOC DSL) Development of requirement specifications 0,5 man-months (300 LOC DSL) Total 1 man-month

slide-28
SLIDE 28

Why do you care

  • Another point of view
  • Train your verification tool
  • Get new verification tasks

28

slide-29
SLIDE 29

Thank You!

29

https://github.com/ldv-klever/klever - Mirror https://forge.ispras.ru/projects/klever - Issue tracker https://github.com/17451k/cif - CIF https://github.com/17451k/clade - Clade http://linuxtesting.org/kernel - Other links and verification projects

slide-30
SLIDE 30

Build Base

  • Various information about the program
  • Source code
  • Build command graph
  • File dependencies graph
  • Callgraph
  • Easy to access
  • Movable archive with all sources and data
  • Python API to access the data

30

slide-31
SLIDE 31

Summary

Decomposition Environment Modeling Requirement Specifications Development Analyzing results Development Manually prepared decomposition specification Coarse model without restrictions Empty requirement Code coverage Decomposition algorithms Scenario model builders Requirement specifications, common model Code coverage, marks, tags Refinement Algorithms to verify libraries Environment model specifications, tests Requirement specifications, common model, tests Code coverage, marks, tags Verification

  • Common model

Code coverage, marks, tags

31

slide-32
SLIDE 32

Verification Time

Verification Job 2 physical cores 4 physical cores 30 * 4 physical cores Serial device drivers (30KLOC) 5h 2.7h 0.5h All device drivers (3MLOC) 600h 195h 11h

32