A perspective user's view of the OOT supplement being introduced in the upcoming DO-178C avionics standard.

1. DO178C/ED12C OOT
A User’s Perspective
Cyrille Comar Hugues Bonnin Fred Rivard
Certification Together International Conference,
Toulouse, October 2010

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

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

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

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

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

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

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

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

10. 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;

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

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

13. Virtualization :
the Java Virtual Machine case

14. 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 bytecode
but with DO178-B...

15. 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”

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

17. CTIC 2010 17
Development principle
for a Java Software (1/2)
Java
Application
JVM Platform
HW targetExecutable
Code
Design
Specification
Executable
Code
Design
Specification

18. 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
ApplicationonJVM
ontarget
smallpartof
integrationtests
Application exec. on JVM
JVM exec. on HW

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

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

21. 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 JVM
JVM execution on the
target
Test JVM
Single test
battery
Stage 1 Stage 2

22. Dynamic Memory
Management : the Java
Garbage Collector example

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

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

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

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

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

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

29. Conclusion

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

31. CTIC 2010 31
Thank you.