DO-178C OOT supplement: A user's perspective

DO178C/ED12C OOTA User’s Perspective

Cyrille Comar Hugues Bonnin Fred Rivard

Certification Together International Conference,Toulouse, October 2010

CTIC 2010 2

Agenda

3 examples of DO178C/OOT usage

1. Inheritance : Liskov Substitution Principle (LSP) with Ada

2. Virtualization : the Java Virtual Machine case

3. Dynamic Memory Management : a Java Garbage Collector example

Inheritance : Liskov Substitution Principle (LSP) with Ada

CTIC 2010 4

Local Type Consistency (TC)

In order to mitigate inheritance vulnerabilities, local type

consistency has to be demonstrated. Indeed, this

property limits reliably inheritance mechanism.

TC is referred in : ◦ OO.4.4 n. : if reuse is planned, maintenance of TC shall be

described.

◦ OO.5.2.2 j. : in design activities, class hiearachy with TC must be

developped with associated LLR.

◦ OO.6.7 : specific verification for Local Type Consistency has to

be done, with added objective in table A-7 (OO-10).

CTIC 2010 5

Local Type Consistency (TC)

1. Formal Methods:◦ Precondition weakening

◦ Postcondition Strengthening

2. Unit Testing (on LLRs associated with Class methods)

◦ Run all tests associated with a class using objects of child classes

3. Pessimistic Testing◦ Verify that all dispatching calls are covered by tests

exercising all methods potentially reachable from a dispatch point

CTIC 2010 6

TC by Formal Analysis

type Class1 is tagged private;

procedure Method (C : in out Class1; I : Integer) with

pre => I > 0;

post => C.Updated;

type Class2 is new Class1 with private;

procedure Method (C : in out Class2; I : Integer) with

pre => I >= 0;

post => C.Updated and C.Sorted;

Ada2012 syntax

must demonstrate that• I > 0 I >= 0• C.Updated and C.Sorted C.Updated

Liskov Substitution Principle:

• Precondition is weakened

• Postcondition is strengthened

CTIC 2010 7

TC by Formal Analysis (2)

Spark = Small Ada + logical annotations

Spark supports limited OO features

Spark already performs this verification

type Class1 is tagged private;

function Updated (C : Class1) return Boolean;

function Sorted (C : Class1) return Boolean;

procedure Method (C : in out Class1; I : Integer);

--# pre I > 0;

--# post Updated(C);

type Class2 is new Class1 with private;

procedure Method (C : in out Class2; I : Integer);

--# pre I >= 0;

--# post Updated(C) and Sorted (C);

H1: updated(fld_inherit(c)) .

H2: sorted(fld_inherit(c)) .

->

C1: updated(fld_inherit(c)) .

H1: i > 0 .

->

C1: i >= 0 .

Spark produces 2 VCs (Verification Conditions)

CTIC 2010 8

TC by Unit Testing

With proper organization of unit testing, verification is relatively easy to put in place:

◦ Each class has a mirror “test” class

◦ Each method has a mirror “test” method Low-Level Requirements are associated with methods

Corresponding testcases are associated to the “mirror” test method

◦ Group all the tests related to a class in a testsuite

◦ Apply this testsuite to objects of the class

◦ Apply this testsuite to objects of subclasses

Verify the LLRs

associated with

the class

Verify type

consistency

CTIC 2010 9

TC by Unit Testing

package Example is

type T1 is tagged private;

procedure M1 (X : T1);

function F1 (X : T1) return Integer;

type T2 is new T1 with private;

overriding procedure M1 (X : T2);

-- inherit F1 (X : T2)

end Example;package Example.Unit_Tests is

type Test_T1 is new Root_Class_Test with

record Ptr : access_T1_Class; end record;

procedure Test_M1 (X : Test_T1);

procedure Test_F1 (X : Test_T1);

type Test_T2 is new Test_T1 with private;

overriding procedure Test_M1 (X : Test_T2);

-- inherit Test_F1 (X : Test_T2)

end Example.Unit_Tests;

LLR1_M1

LLR2_M1

LLR1_M1_TestCase1

LLR1_M1_TestCase2

…

+M1()

+F1()

T1

+M1()

T2

+Test_M1()

+Test_F1()

-Ptr

T1_Test

+Test_M1()

T2_Test

1

1

CTIC 2010 10

TC by Unit Testing

package body Example.Test_Suites is

procedure T1_Test_Suite (T : Test_T1) is …

procedure T2_Test_Suite (T : Test_T2) is

begin

Test_M1 (T);

Test_F1 (T); -- call inherited test

end T2_Test_Suite;

end Example.Test_Suites;

Procedure My_Test is

T2_Obj : Test_T2 := (Root_Class_Test with new T2);

begin

-- regular testing on T2

Example.Test_Suites.T2_Test_Suite (T2_Obj);

-- verify that T2 can substitute T1 safely

Example.Test_Suites.T1_Test_Suite (Test_T1(T2_Obj));

end My_Test;

CTIC 2010 11

TC by Pessimistic Testing

Locate all dispatching calls in the application

For each, infer every method that can be called

Verify that Req based testing cover all such cases

CTIC 2010 12

TC by Pessimistic Testing

procedure Do_Something (Obj1 : T1’Class; Obj2 : T2’Class) is

begin

…

Obj1.M1;

…

Val := Obj2.F1;

…

end Do_Something;

T2’s F1

T2’s M1

T1’s M1

…

Do_Something (My_Obj1, My_Obj2);

…

Do_Something (My_Obj2, My_Obj2);

…

Enough to achieve stmt coverage but

Not enough for Type Consistency verif

Necessary to complete “pessimistic testing”

Virtualization : the Java Virtual Machine case

CTIC 2010 14

Multilayering needs

virtualization has multiple known interests for productivity and industrialisation◦ SW/HW independance

◦ simulation easier

◦ portability improved

but for safety too :◦ breakdown of complexity (« divide and conquer »)

◦ in case of Java :

stability of Java Bytecode (10+ years)

formal properties of bytecodebut with DO178-B...

CTIC 2010 15

Executable (on target)

Code

Design

Specification

Introduction

of

Virtualizatio

n

No

room

for

Java

Byte

Code

DO178-B approach

Executable (on target)

Code

Design

Specification

Byte-Code (on VM)

DO178C/OOT approach

OO.4 “The target environment is either a target computer or a combination

of virtualization software and a target computer. Virtualization software

also needs to comply with DO-178C/ED-12C and applicable supplements”

CTIC 2010 16

DO178C ref. on virtualization

OO.4.2 m.◦ « Describe any planned use of virtualization » and « This

data [byte code] should be treated as executable code »

OO.C.7.7◦ main vulnerability is « the code of a given virtualization

layer may be considered to be data, consequently, tracing may be neglected, and verification may be insufficient »

OO11.7 g., OO11.8 f.◦ standards (design and code) must include contraints on

usage of virtualization

CTIC 2010 17

Development principle for a Java Software (1/2)

Java Application

JVM Platform

HW targetExecutable

Code

Design

Specification

Executable

Code

Design

Specification

CTIC 2010 18

Development principle for a Java Software (2/2)

Tests principles : « IMA-like » process

Application on JVM

main part of appl. HLR,

LLR tests

JVM on target

main part of JVM HLR,

LLR tests Ap

plic

atio

n o

n J

VM

on

ta

rge

t

sm

all

part

of

inte

gra

tio

n te

sts

Application exec. on JVM

JVM exec. on HW

CTIC 2010 19

Constraints on Application devt.

development of application is not changed

but « executable object code » is Java bytecode, and the target is a JVM.

it allows to executes tests on any JVM, considering that target environment is representative of final HW target. ◦ standardisation of the JVM greatly helps for this demonstration

CTIC 2010 20

Constraints on JVM devt. (1)

Devt. of the JVM must be done at least at the same SW level as the application.

JVM HLR and LLR are principally described in Java Virtual Machine specification (the « blue book »).

Robust and deterministic algorithms must be chosen, and described in LLRs, to implement the JVM (see for example Garbage Collector in next part)◦ The simplest are the choices, the easiest is the

demonstration.

CTIC 2010 21

Constraints on JVM devt. (2) :JVM Tests strategy

HW target

JVM Java tests

JVM

tests execution on JVM

JVM Java Bytecode

JVM target bytecode

JVM execution on a Test JVMJVM execution on the target

Test JVM

Single test battery

Stage 1 Stage 2

Dynamic Memory Management : the Java Garbage Collector example

CTIC 2010 23

DO178C ref. on Dynamic Memory Management

OO.C.7.6◦ vulnerabilities are listed and explained, with guidelines

OO.5.2.2 (design activities) : ◦ k. « As part of the software architecture, develop a

strategy for memory management »

OO.11.7 g. et OO.11.8 f.◦ standards (design and code) must include contraints on

usage of memory management

OO.6.8◦ specific verification for Dynamic Memory Management

has to be done, with added objective in table A-7 (OO-11), covering all the vulnerabilities explained in OO.C

CTIC 2010 24

Memory ManagementTable OO.C.7.6.3 : where sub-objectives are addressed

MMI : Memory Management Infrastructure AC : Application

With automatic heap managament allocation, application transfers dynamic memory management problems to the infrastructure

this is a main advantage of using a Garbage Collector (GC)

a b c d e f g

Object pooling AC AC AC AC AC N/A MMI

Stack allocation AC MMI MMI AC AC N/A MMI

Scope allocation MMI MMI MMI AC AC MMI MMI

Manual heap allocation AC AC* AC AC AC N/A MMI

Automatic heap allocation MMI MMI MMI AC MMI MMI MMI

Sub-objectives (OO.6.8.2)Technique

CTIC 2010 25

7 vulnerabilities in DMM

a. Ambiguous References

b. Fragmentation Starvation

c. Deallocation Starvation

d. Heap Memory Exhaustion

e. Premature Deallocation

f. Lost Update and Stale Reference

g. Time bound Allocation or Deallocation

MMI

MMI

MMI

MMI

MMI

MMI

AC

CTIC 2010 26

Verify GC by tests against vulnerabilities

these verification points are a sort of minimal requirements for a DMM infrastructure.

They all can be tested by adequate stress tests

For example, property e. « Premature Deallocation » ◦ 6.8.2.e states « Verify that reference consistency is maintained, that is,

each object is unique, and is only viewed as that object. »

◦ One test could be :

one thread fill an array with objects ;

another one compare randomly cells of the array (a[x]==a[y]) ;

one third thread destroys the objects.

This process is repeated at a high rate and during a long period.

The comparison must never be true.

CTIC 2010 27

Verify GC by analysis against vulnerabilities (1/2)

The fine characteristics of the GC give supplementary LLRs◦ Stop-the the-world / concurrent

◦ Mark-sweep / copy

◦ Compact / not compact

◦ Exact / conservative pointers

◦ Work / time based ...

CTIC 2010 28

Verify GC by analysis against vulnerabilities (2/2)

For example,b. Fragmentation Starvation

c. Deallocation Starvation

g. Time bound Allocation or Deallocation

are well demonstrated by Shoeberl works, for concurrent-copy GC,

these charactristics can be used to give some sound verification of vulnerabities

with periodic GC.

Conclusion

CTIC 2010 30

Conclusion

DO178C/OOT supplement is a real guide to go to certification with OO features◦ it gives the necessary constraints to make OO programs

safe

◦ it gives the sufficient genercity to accept any known OO technology

◦ it gives didactical material (APP.C)

Thanks to this new DO178 version, modern OO technology will finally be embedded in our modern aircrafts.

CTIC 2010 31

Thank you.