FMCAD 2008
Considerations in the Design and Verification of Microprocessors
for Safety-Critical and Security-Critical Applications
David Hardin
Rockwell Collins Advanced Technology Center
Cedar Rapids, IA
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Rockwell Collins
Provider of Communications and Aviation Electronics Systems
for Commercial and Government Applications Worldwide
Government
~ 52%
Commercial
~ 48%
Government Systems
Commercial Systems
• Precision Strike
• Surface Solutions
• Mobility & Rotary Wing
• C3I
• Air Transport
• Business & Regional
• Cabin Systems
• eFlight
Engineering & Technology
Advanced Technology Center
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
2
High Assurance Systems
DO-178B (DO-254) Software/System
Assurance Levels
– Level A: Catastrophic Failure Protection
– Level B: Hazardous/Severe Failure
Protection
– Level C: Major Failure Protection
– Level D: Minor Failure Protection
– Level E: Minimal Failure Protection
RCI processors are in use in Level-A boxes
– Boeing 777, 767, 757, 737 Autopilot
– Boeing 747-400 Displays
– Verified by “Formal Process”
• Use of Concise/“Simple” Design
• Design Walkthroughs/Inspections
• Coverage and Functional/Stress Testing
Common Criteria Evaluation Assurance Levels
– EAL 7: Formally Verified Design and Tested
– EAL 6: Semi-formally Verified Design and
Tested
– EAL 5: Semi-formally Designed and Tested
– EAL 4: Methodically Designed, Tested and
Reviewed
– EAL 3: Methodically Tested and Checked
– EAL 2: Structurally Tested
– EAL 1: Functionally Tested
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
3
High-Assurance Hardware Development: A SafetyCritical Community Perspective
• RTCA DO-254: Design Assurance Guidance for Airborne
Electronic Hardware
• Intended for complex hardware including PLDs and ASICs
• Defines criticality levels: A (highest assurance), B, C, D
• Process-oriented document
• Coverage Testing emphasized
• Formal methods not emphasized, but can be used in
conjunction with traditional testing
– e.g., formal equivalence checking tools
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
4
DO-254 Hardware Design Process
• Requirements Capture
– Requirements documented, allocated to design elements
• Conceptual Design
– Architectural level Design documented
– Traceability back to requirements
• Detailed Design
– Detailed Design Document
– Interface documentation
• Implementation
• Product Transition
DO-254 processes provide input used in the Type Certification
(performed by FAA/JAA) for the aircraft
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
5
DO-254 Supporting Processes
• Applied at each step
•
•
•
•
Verification and Validation
Configuration Management
Process Assurance
Certification Liasion
– Typically via Designated Engineering Representatives (DERs)
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
6
DO-254 Verification
• Verification Independence
– Designer doesn’t test own code
• Requirements-based test on both RTL and gate-level design
• Traceability from requirements to tests and results
• Coverage analysis
– Typically use combination of directed and automated test stimuli to
achieve complete coverage
• Advanced methods (for level A/B)
– Functional Failure Path Analysis
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
7
High Assurance Hardware Development: A SecurityCritical Community Perspective
•
•
•
•
Defined by the Common Criteria
Evidence-oriented (as opposed to process-oriented)
Emphasis on third-party penetration testing
Formal methods required at the highest assurance levels
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
8
Common Criteria
• Common Criteria for Information Technology Security
Evaluation
– Internationally recognized standard
– Provides a common language for vendors and
consumers
• Evaluation Assurance Levels (EALs)
• National Information Assurance Partnership (NIAP)
– US Common Criteria Certification Authority
• National Security Agency (NSA)
– Evaluation Authority for formal methods work for ‘high
assurance’ certifications in the USA
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
9
Common Criteria Evaluation Assurance Levels
•
•
•
•
•
•
•
EAL
EAL
EAL
EAL
EAL
EAL
EAL
1
2
3
4
5
6
7
–
–
–
–
–
–
–
functionally tested
structurally tested
methodically tested and checked
methodically designed, tested, and reviewed
semiformally designed and tested
semiformally verified design and tested
formally verified design and tested
The “EAL scale” is basically logarithmic in evaluation
difficulty – like the Category scale for hurricanes ;-)
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
10
Degrees of Formality
• Informal
– Written as prose in natural language
• Semiformal
– Specifications written in a restricted syntax language, internally
consistent. Correspondence demonstration requires a structured
approach to analysis
• Formal
– Written in a notation based upon well-established mathematical
concepts
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
11
Protection Profiles and Security Targets
• These documents tailor the Common Criteria requirements
– Requirements profiles
• Protection Profiles (PP) specifies requirement profiles for a class
of applications
– Separation Kernel Protection Profile
– Optional artifact
• Security Target applies to a specific application
– Each certification must have a security target
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
12
Formal Methods and the CC
• Formal methods analysis satisfies the following CC
sections
– ADV_FSP (Functional Specification)
– ADV_HLD (High-Level Design)
– ADV_LLD (Low-Level Design)
– ADV_RCR (Representation Correspondence)
– ADV_SPM (Security Policy Modeling)
• Fundamental properties of the system are proven
• System may be modeled in a formal language
– Multiple models with a decreasing degree of
abstraction
– Correspondence between levels rigorously
proven.
• Properties proven on each model
• Most detailed model shown to correspond to
implementation by code-to-spec review
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
13
Formal Modeling Philosophy
•
Computing System is Modeled Functionally
– No Side-Effects!
– Step Function (Next)
– Multiple levels of abstraction
– Lowest level (for this work) typically a microcode interpreter
•
Information is Modeled Indirectly …
– Not “What the Information is” …
... in terms of Location (indices)
– But “Where the Information is”
• Secret information is here; Unclassified information over there
•
•
Communication
– Dynamic Process involving the movement of information
(information flow) from one location to another
– Associated with some action in the system
– Carried out by functions
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
14
2-Model Assurance Architecture
Application (e.g. firewall)
Use in Application Proof
Formal Security Policy
Proofs of Security Policy
End
Model
CorrespondenceHigh-Level
Proofs
Low-Level Model
Start
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Mapping Functions
15
Validating the Low-Level Model
Q: Is the model the right model?
A: The ‘Code-to-Spec’ review with NSA evaluators determines that the lowestlevel model accurately depicts the system’s true behavior
?
=
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
16
RCI Microprocessor Technology
High assurance,
Deterministic, Hard Real
Time, Low power
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
17
AAMP7G Microprocessor
 Utilized in a number of Rockwell Collins navigation
and communications products
 High Code Density (2:1 Over CISC, 4:1 Over RISC)
 Low Power Consumption
 Long life cycle relative to other commercial CPUs
 Screened for full military temp range (-55 C to
+125 C)
 Design artifacts owned by Rockwell Collins
 Architecturally-defined threads, executive/user
modes, exception handling
 Intrinsic Partitioning
 Very low latency
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
18
AAMP7G Intrinsic Partitioning Verification
• Allows multiple independent applications to execute
concurrently on the same CPU
• AAMP7G Enforces Process Isolation
• “Separation Kernel in Hardware”
•
Ripe target for formal verification
– Desired due to use in applications that require separation of data at
different classification levels.
– Requirements similar to Common Criteria EAL 7, which entails an
evaluation based in part on the use of formal methods.
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
19
AAMP7G Design for Verification Characteristics
• AAMP7G partitioning logic is (relatively) localized in the design
• AAMP7G partitions are controlled by “Trusted mode” microcode
– No software in separation kernel
– Non-trusted mode microcode cannot affect partitioning data
structures
• Simple range-based memory protection
– Physical memory model
– Partitions can define up to eight memory regions
• code/data, read/write attributes
• Strict Time partitioning
– Partitions have fixed time allocations
– Partitions execute in round-robin fashion according to a partition
schedule defined by the partitioning data structures
• Partition-aware interrupts
– Interrupts for non-current partition are pended for delivery when
that partition becomes active
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
20
The ACL2 Theorem Prover
• A system for the development of machinechecked proofs for theorems expressed in
a logic that is an applicative subset of
Common Lisp
– Applicative subset == no side effects
• Developed by Kaufmann and Moore at the
University of Texas and Austin
• Since ACL2 models are also applicative
Common Lisp programs, they can be
executed
• First-order logic
• Proofs are guided by the introduction and
proof of lemmas that guide the theorem
prover’s simplification strategies
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
21
ACL2 Syntax
• Lisp-style syntax
– Prefix notation
• (+ 3 4)
– Let statements bind variables
• (let ((x (+ 3 4))) …)
– Pass-by-value
• No aliasing
• No loop constructs
– Looping implemented by recursive functions
• Obligated to prove termination
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
22
ACL2 Syntax
• Side-effect free
– No global variables, all actions are explicit
– A structure representing system state passed to and
returned from most model functions
• ACL2 single-threaded objects (stobj) – allow state object
to be updated ‘in place’ “under the hood”
• Syntactic Sugar
– Macros can be used to enhance readability and make the
resulting models look more like the implementation (C code
in many cases)
• RCI reader macro
(%
(x = (+ 3 4))
(y = 2)
(* x y))
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
23
Outline of Typical ACL2 Theorem
(defthm a-theorem
(implies
(and
(hyp-1 a)
(hyp-2 b c))
(equal
(complicated-expression a b c)
(simple-expression a b c))))
Hypothesis
Conclusion
Proving this to be true will add a rewrite rule to the ACL2 session
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
24
Security Policy
• Informal Security Policy speaks
to:
– Information Flow Control
– Data Isolation
– Sanitization
• Need for Formalization
– Precise Mathematical
Description
– Suitable for Formal Analysis
• Formal Security Policy should be
usable as an axiom to prove
– (Non-)Infiltration
– (Non-)Exfiltration
– Mediation
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
X
Y
Z
X
Y
Z
X
Y
Z
25
The GWV Formal Security Policy
• GWV security policy developed for AAMP7G verification
– Named after its authors: Greve (RCI), Wilding (RCI), and
vanFleet (NSA)
• GWV validated by use in proof of firewall system exhibiting
desired infiltration, exfiltration, mediation properties
• GWV only applicable to a narrow class of systems
– Strict temporal partitioning
P1
– Kernel state cannot be influenced by
K
execution of code within partitions
P2
P3
• Later generalized for a wider range of systems
– GWVr2, used to verify a commercial RTOS kernel
P1
K
P2
P3
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
26
Security Policy Definitions
• SEG
– Arbitrary piece of system state
• DIA (Direct Interaction Allowed)
– A function that computes the set of segs that can/may
influence a particular seg
– Embodiment of data-flow policies
• CURRENT
– The current partition
• GET-SEGS
– Function that computes the set of segs that belongs to a
particular partition
• NEXT
– Model of the system being analyzed
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
27
GWV Separation Theorem
(defthm gwv
(let ((dia-segs (intersection (dia seg) (get-segs (current st1)))))
(implies
(and
(equal (select-list dia-segs st1)
(select-list dia-segs st2))
(equal (current st1)
(current st2))
(equal (select seg st1)
(select seg st2)))
(equal (select seg (next st1))
(select seg (next st2))))))
Function
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Conclusion
28
GWV Separation Theorem
(defthm gwv
(let ((dia-segs (intersection (dia seg) (get-segs (current st1)))))
(implies
(and
(equal (select-list dia-segs st1)
(select-list dia-segs st2))
(equal (current st1)
(current st2))
(equal (select seg st1)
(select seg st2)))
(equal (select seg (next st1))
(select seg (next st2))))))
Index
Function
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Conclusion
29
GWV Separation Theorem
(defthm gwv
(let ((dia-segs (intersection (dia seg) (get-segs (current st1)))))
(implies
Hypothesis
(and
(equal (select-list dia-segs st1)
(select-list dia-segs st2))
(equal (current st1)
(current st2))
(equal (select seg st1)
(select seg st2)))
(equal (select seg (next st1))
(select seg (next st2))))))
Index
Function
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Conclusion
30
GWV Separation Theorem
DIA
(defthm gwv
(let ((dia-segs (intersection (dia seg) (get-segs (current st1)))))
(implies
Hypothesis
(and
(equal (select-list dia-segs st1)
(select-list dia-segs st2))
(equal (current st1)
(current st2))
Has also been formalized by
(equal (select seg st1)
John Rushby in the logic of
(select seg st2)))
the PVS theorem
(equal (select seg (next st1))
Proving system
(select seg (next st2))))))
Index
Function
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Conclusion
31
Relationship to Classical Noninterference
"Low-security behavior of the program is not affected by any
high-security data."
Goguen & Messeguer 1982
H1
L1
H3
L1
L
H2 L2
H4 L2
Graphic: Steve Zdancewic: “Secure Information Flow and CPS”, ESOP’01
Recent work by Greve: Noninterference can be shown to follow from GWV.
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
32
AAMP7G Formal Verification
Common Criteria
EAL7 Proof Obligations
Security
Policy
Formal Verification
Abstract
Abstract
ModelModel
Formal Verification
Low-Level
Low-Level
KernelKernel
ModelModel
Code-to-Spec Reviews
Microcode
Microcode
AAMP7
AAMP7G
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
33
Partition Execution Model
• Begins with the Loading of the Current Partition
• Ends with the Saving of the Current Partition State
– And the updating of the value of “current partition”
Time
step
Partition Event
step
step
step
secure state
save partition
load partition
execute
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
34
AAMP7G Detailed Formal Processing Model
START STATE
Partition Step
Thread Context Switches
Subroutine Invocations
BasicBlocks
Abstract Instruction Steps
Concrete Instruction Steps
Abstract Microcode Steps
Concrete Microcode Steps
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
35
Key Issue: Data Structure Representation
Programmer’s view -“boxes and arrows”
NODE
NODE
NODE
INFO
INFO
Reality –
mapped into a single linear
address space
0xabcdef
Clear that write of one part of data
structure doesn’t affect read of another part
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Same read/write independence not so easy
to establish when mapped to linear address
space
36
GACC: Generalized Accessor Library
• A means of describing linearized data structures
– Distinguishes pointer and data locations
• Implemented as a reusable ACL2 library
• Rules for resolving read/write operations
– (read addr1 (write addr2 value ram)) = (read addr1 ram)
– (read addr1 (write addr1 value ram)) = value
• Rules for preserving structure
– Writes to data locations don’t change data structure shape
• Efficient rules for disjoint/subset/unique relations
– Linear Time/Space
– Free-variable matching
– Meta-rules
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
37
Code-to-Spec Review Details
• Goal: Validation of Low-Level Model
– No “Proof of Correctness”
– Must be done informally
• The Code-to-Spec Review
– Inspection to determine whether the “code” implements the
“specification”
– Requires some understanding of both
– Implementers have a “meeting of the minds” with
evaluators
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
38
Code-to-Spec Review Sample
Microcode
Formal Model
;=== ADDR: 052F
(st. ie = nil)
(Tx = (read32 (vce_reg st) (VCE.VM_Number)))
;=== ADDR: 0530
(st. Partition = Tx)
;=== ADDR: 0531
(TimeCount = (read32 (vce_reg st) (VCE.TimeCount)))
;=== ADDR: 0532
(PSL[0]= TimeCount st)
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
;---------------------------------------------------------------------;=== ADDR: 052F
A]
CONT ;
H] clear InterruptEnable, read VM number
IE=0
\
T=BADDR.READ32(T) ;
L] hold VM number (a.k.a. partition number) in T
\
T=T ;
;---------------------------------------------------------------------;=== ADDR: 0530
A]
CONT ;
H] load VM number into MSQ partition register
P=T
\
T=T ;
L] unused
\
T=T ;
;---------------------------------------------------------------------;=== ADDR: 0531
A]
CONT ;
H] locate TimeCount in VCE
R=VCE.TimeCount W=RFB(VCE_REG) \
T=R+W ;
L] read TimeCount
\
T=BADDR.READ32(T) ;
39
AAMP7G Verification Summary
• Developed formal description of
separation for uniprocessor,
multipartition system
• Modeled trusted AAMP7G microcode
• Constructed machine-checked proof of
separation on the AAMP7G model
– ACL2 theorem prover checked
– Operations on pointer-laden, aliased data
• Model subject of intensive code-to-spec
review with AAMP7G microcode
• Satisfied formal methods requirements
for AAMP7G - certification awarded in
May 2005
– AAMP7G was “verified using Formal
Methods techniques as specified by the
EAL-7 level of the Common Criteria” and
is “capable of simultaneously processing
unclassified through Top Secret
Codeword”
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
40
AAMP7G Formal Verification: Only one part of the
MILS certification evidence
Evaluation Process
Development Process
Common Criteria
NSA Certification
Rqmnts (TSRD)
(VOL III: Assurance Rqmnts)
Common Criteria
(VolII: Functional Rqmnts)
Formal Region
UIC
Protection Profile
(Separation Kernel)
TEO
Security Target
(AAMP7G SKPS)
Assurance Plan
Configuration
Management Plan
Formal Security
Policy Model
Informal Security
Policy Model
Correspondence
Report
Descriptive Top Level
AAMP7G Spec
Abstract
Machine Model
Correspondence
Report
TOC
Descriptive Low Level
AAMP7G Spec
Implementation
Machine Model
AAMP7G SPKS Fail
Safe Design
Analysis (FSDA)
Validation
Report
AAMP7G SPKSSec'ty Verif. Tst
(SV Plan, Procedure, Test, Rpt)
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Architectural
Description
Philosophy of
Protection Rpt
Covert Channel
Analysis Rpt
Security Features
User's Guide
Trusted Facilities
Manual
41
Moving Forward
• Now that we have a formally verified MILS partitioning system,
we can build systems that handle multiple levels of
classification using the same CPU, for example:
– Crypto Devices
– Cross Domain Systems
• Partitioning can also be used as a convenient “design
decomposition” tool
– Partitions can be developed separately, since they have a fixed
schedule and memory bounds, and then brought together at
software integration time
– We can provide separate partitions for common “miscellaneous”
functions such as health monitoring, audit
• System verification then becomes a composition of individual
partition verification activities
– Partition verification activities often require an analysis of
information flow within the individual partitions
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
42
Cross Domain Solutions
• Cross Domain Solution
(CDS) is a term the DoD
applies to systems that
transport data from one
classification domain to
another or re-classify data
from one classification to
another
• Guards and data pumps are
Cross Domain Solutions
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
43
Verifying Partition Execution
• Have written an instruction-level simulator for the AAMP in
ACL2
– ~100 KSLOC with all Rockwell Collins support books
– ~500 MB Lisp heap required
• Can be used as a processor simulator, as well as a vehicle for
proof
– Validated by loading AAMP processor diagnostic tests into
(simulated) memory, and running the model
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
44
ACL2 session
Process Stack
Disassembly
Console
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
AAMP7G ACL2
Formal Model
Integration with
Eclipse AAMP7G
Tools
Reasoning about machine code
•
•
If machine starts at a state satisfying program’s precondition
(entrypoint assertion), then
– Partial correctness: if the machine ever reaches an exitpoint
state, then the first exitpoint reached satisfies the program’s
postcondition (exitpoint assertion).
– Termination: the machine will eventually reach an exitpoint
However, we don’t want to
– write and verify a VCG
– manually define a clock function
• computes for each program state exactly how many steps are needed
to reach the next exitpoint
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
46
An Object Code Verification Method – Compositional
Cutpoint Technique
Entry
• Sound and automatic theorem proving
technique for generating verification
conditions from a small-step operational
semantics, such as provided by the AAMP7G
ACL2 instruction set simulator
• Inspired by J Moore presentation at HCSS
2004
• Cutpoints and their state assertions for a
given subroutine must be specified
• Symbolic simulation of processor model takes
us from cutpoint to cutpoint, until we reach
subroutine exit
• Compositionality: Once cutpoint proof is done
for a given subroutine, we don’t have to
reason about it again if it’s called by another
subroutine
• No Verification Condition Generator required
• Technique has been further explored by
Matthews, Smith, Univ. of Texas group
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Cutpoint
Exit
47
Another Technique: Model-Based Development Verification
In Model-Based Development (MBD), developers build graphical models that can be
executed and analyzed before implementation, then used to automatically generate
implementation code or hardware and test cases.
sf_car.mdl
Choose Start from
the Simulation menu
to run the simulation.
impeller torque
Ti
Ne
Ne
Ti
engine RPM
throttle
gear
Engine
Nout
User Inputs
Brake
Tout
speed
gear
up_th
Domain-specific
graphical notation
output torque
Vehicle
transmission
transmission speed
Throttle
CALC_TH
down_th
Double-click to
open the GUI
and select an
input maneuver
shift_logic
down_th
up_th
run()
gear
vehicle
speed
throttle
vehicle mph
(yellow)
& throttle %
Threshold Calculation
Mux
if (ActiveStandby_DWork.is_active_c2_ActiveStandby == 0) {
ActiveStandby_DWork.is_active_c2_ActiveStandby = 1U;
ActiveStandby_enter_internal_c2_ActiveStandby();
} else {
switch (ActiveStandby_DWork.is_c2_ActiveStandby) {
case ActiveStandby_IN_Side1Failed:
if (!ActiveStandby_U.Side1Failed) {
…
Dynamic simulations
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
Automated
static analysis
Automated code generation
48
Rockwell Collins Translation Framework
NuSMV
Simulink
Simulink
Gateway
SCADE
Reactis
StateFlow
Simulink
Gateway
Prover
Lustre
PVS
Safe State
Machines
Design
Verifier
SAL Symbolic
Model Checker
Rockwell Collins/U of Minnesota
Esterel Technologies
SRI International
MathWorks
Reactive Systems
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
ACL2
SAL
SAL Bounded
Model Checker
SAL Infinite
Model Checker
49
Testing vs. Verification – UAV Redundancy Manager
Subsystem/
Charts /
Blocks
Transitions /
TT Cells
Reachable
State Space
Properties
Triplex voter
10 / 96
3 / 35 / 198
6.0 * 1013
48
Failure
processing
7 / 42
0/0/0
2.1 * 104
6
1
6 / 31
2 / 26 / 0
1.32 * 10
11
8
[B]
DST
[C]
Data Store
Read
input_c
5
[status_a]
status_a
6
[status_b]
status_b
7
[status_c]
status_c
8
23 / 169
5 / 61 / 198
N/A
[DSTi]
[A]
dst_index
Totals
[trigger]
input_a
3
input_b
4
Reset
manager
sync<>
sync
2
62
Extract Bits u16
[0 3]
[MS]
Index
Vector
mon_f ailure_report
[trigger]
[status_a]
status_a
[status_b]
status_b
[status_c]
status_c
[prev_sel]
prev _sel
f ailure_report
[A]
f ailure_report
input_a
[DSTi]
f ailreport
[B]
input_b
[C]
input_c
trip_level
trip_lev el
failreport
[A]
input_a
[B]
input_b
[C]
input_c
[DSTi]
Failure_Isolation
1
DOC
Text
failure_report
Results
• Spent 133 Hours Modeling Checking
• Found 12 Errors
• Nearly 200 hours of testing found no errors
trip_level
pc
2
persistence_cnt<pc>
trip_level1
persist_lim
persistence_cnt
persist_lim
pc
persist_lim
persistence limit
[MS]
totalizer_lim
[trigger]
trigger
[A]
input_a
3
[B]
input_b
totalizer_cnt
[C]
input_c
MS
4
input_sel
tc
totalizer_cnt<tc>
totalizer_lim
[DSTi]
persistence limit1
triplex_input_monitor
input_sel
1
DST_index
z
triplex_input_selector
Unit Delay
Formal verification has found subtle errors that
would likely be missed by traditional testing.
- Lockheed Martin
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
dst_index
Failure_Processing
50
[prev_sel]
MBD Information Flow Analysis
• Rockwell Collins has developed a formally justified technique
for automated information flow analysis of MBD applications
• Gryphon-IF: tool for automatically generate information flow
models from Simulink functional models
• Uses model checker to analyze the augmented model
– Model checking success implies noninterference
1
hw_in
3
lw_in
5
hr_in
principal
Id: SI
[hw_in]
Goto1
principal
Id: UI
[lw_in]
Goto2
principal
Id: SO
[hw_in]
From8
hw_in
[lw_in]
From9
lw_in
hr_in
[lr_in]
From11
lr_in
Goto1
From8
3
[lw_in]
[lw_in]
lw_in
Goto2
5
[hr_in]
hr_in
Goto3
6
[lr_in]
lr_in
Goto4
lw_in
mode_out
hr_in
From10
[lr_in]
lr_in
is_mode_low
[SI_Principal]
lr_val
0
gry _IF_hw_in
From3
Constant
Switch2
gry _IF_lw_in
gry _IF_mode_out
1
[SO_Principal]
lr_val
[UO_Principal]
2
is_mode_high
hr_val
gry _IF_lr_in
From2
Switch2
[lr_in]
gry _IF_hr_in
From1
0
0
Constant1
Buffer_Controller
Goto4
1
is_mode_low
From4
Goto3
principal
Id: UO
hw_in
From9
[UI_Principal]
Constant
6
lr_in
[hw_in]
From11
Buffer_Controller
[hr_in]
[hw_in]
[hr_in]
mode_out
[hr_in]
From10
1
hw_in
Switch1
State
2
hw_val
principal
Id: SI
hw_v al
State
Out1
is_mode_high
4
lw_val
principal
Id: UI
2
hr_val
lw_v al
0
2
hw_v al
hw_val
4
lw_v al
OR
lw_val
Constant1
Buffer
Out1
-CSI_Principal
-CUI_Principal
-CSO_Principal
-CUO_Principal
[SI_Principal]
Goto5
[UI_Principal]
[SI_Principal]
gry _IF_hw_v al
From5
[UI_Principal]
gry _IF_lw_v al
gry _IF_Out1
-CEMPTY
Switch3
Logical
Operator
From6
Buffer
Goto6
[SO_Principal]
OR
4
Goto7
gry_IF_lr_val1
[UO_Principal]
Goto8
-CEMPTY1
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
3
gry_IF_lr_val
gry _IF_State
Switch1
Switch4
Logical
Operator1
51
Conclusions
• The Safety-Critical and Security-Critical communities have
complementary views of high-assurance development
– If you are DO-254 compliant, you still have a lot of work to do in
order to achieve a Common Criteria certification, and vice versa.
– However, if you adopt the careful process and testing regime of DO254, you are more likely to be able to successfully perform formal
verification as per the Common Criteria
• EAL 7 level verification of critical microprocessor functions is
possible if design for verification is considered in advance
• Be sure to consider the needs of the evaluators
– Formal artifacts should be constructed so as to ease the code-tospec review process
– The evaluators should be able to reproduce your proofs
• Code proofs are (still) hard, but the technology is improving
• Model-Based development is becoming more and more
prevalent in the high-assurance development community
© Copyright 2008 Rockwell Collins, Inc.
All rights reserved.
52