FMCAD 2008
description
Transcript of FMCAD 2008
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
Considerations in the Design and Verification of Microprocessors for Safety-Critical and Security-Critical Applications
David HardinRockwell Collins Advanced Technology Center
Cedar Rapids, IA
FMCAD 2008
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
2
Government~ 52%
Commercial~ 48%
Provider of Communications and Aviation Electronics Systems for Commercial and Government Applications Worldwide
Commercial Systems• Air Transport• Business & Regional• Cabin Systems• eFlight
Government Systems• Precision Strike• Surface Solutions• Mobility & Rotary Wing• C3I
Engineering & Technology
Advanced Technology Center
Rockwell Collins
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
3
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.
4
High-Assurance Hardware Development: A Safety-Critical 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.
5
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.
6
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.
7
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.
8
High Assurance Hardware Development: A Security-Critical 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.
9
• 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
Common Criteria
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
10
• EAL 1 – functionally tested• EAL 2 – structurally tested• EAL 3 – methodically tested and checked• EAL 4 – methodically designed, tested, and reviewed• EAL 5 – semiformally designed and tested• EAL 6 – semiformally verified design and tested• EAL 7 – formally verified design and tested
The “EAL scale” is basically logarithmic in evaluation difficulty – like the Category scale for hurricanes ;-)
Common Criteria Evaluation Assurance Levels
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
11
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.
12
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.
13
• 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
Formal Methods and the CC
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
14
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.
15
High-Level Model
Formal Security Policy
2-Model Assurance Architecture
Proofs of Security Policy
Low-Level Model
Mapping Functions
Correspondence Proofs
Start
End
Application (e.g. firewall)
Use in Application Proof
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
16
Q: Is the model the right model?A: The ‘Code-to-Spec’ review with NSA evaluators determines that the lowest-
level model accurately depicts the system’s true behavior
?=
Validating the Low-Level Model
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
17
High assurance, Deterministic, Hard
Real Time, Low power
RCI Microprocessor Technology
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
18
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.
19
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.
20
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.
21
The ACL2 Theorem Prover
• A system for the development of machine-checked 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.
22
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.
23
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.
24
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.
25
• 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
X Y Z
X Y Z
X Y Z
Security Policy
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
26
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– Kernel state cannot be influenced by execution of code within partitions
• Later generalized for a wider range of systems– GWVr2, used to verify a commercial RTOS kernel
K
P1
P2
P3
K
P1
P2
P3
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
27
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.
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))))))
Function Conclusion
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
29
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))))))
ConclusionFunctionIndex
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
30
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))))))
Hypothesis
ConclusionFunctionIndex
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
31
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))))))
Has also been formalized by
John Rushby in the logic of the
PVS theorem
Proving system
Hypothesis
ConclusionFunctionIndex
DIA
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
32
Relationship to Classical Noninterference
"Low-security behavior of the program is not affected by any high-security data."
Goguen & Messeguer 1982
H1 L1
L2H2
H3 L1
L2H4
L
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.
33
AAMP7G Formal Verification
AAMP7
Microcode
Low-LevelModel Kernel
AbstractModel
Formal Verification
Formal Verification
Common CriteriaEAL7 Proof Obligations
SecurityPolicy
Code-to-Spec Reviews
AbstractModel
Low-LevelModel
Kernel
Microcode
AAMP7G
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
34
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”
Partition EventTime
step step step step
secure state
load partition
execute
save partition
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
35
AAMP7G Detailed Formal Processing Model
START STATE
Concrete Instruction Steps
Abstract Instruction Steps
Subroutine Invocations
Thread Context Switches
Abstract Microcode Steps
Partition Step
BasicBlocks
Concrete Microcode Steps
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
36
Key Issue: Data Structure Representation
NODE
INFO
NODE NODE
INFO
0xabcdef
Programmer’s view -- “boxes and arrows”
Reality – mapped into a single linear
address space
Same read/write independence not so easy to establish when mapped to linear address
space
Clear that write of one part of data structure doesn’t affect read of another part
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
37
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.
38
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.
39
;=== 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)
;----------------------------------------------------------------------;=== ADDR: 052FA] 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: 0530A] CONT ;H] load VM number into MSQ partition register P=T \ T=T ;L] unused \ T=T ;;----------------------------------------------------------------------;=== ADDR: 0531A] CONT ;H] locate TimeCount in VCE R=VCE.TimeCount W=RFB(VCE_REG) \ T=R+W ;L] read TimeCount \ T=BADDR.READ32(T) ;
Formal Model
Microcode
Code-to-Spec Review Sample
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
40
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.
41
AAMP7G Formal Verification: Only one part of the MILS certification evidence
Formal Region
Common Criteria(Vol II: Functional Rqmnts)
Protection Profile(Separation Kernel)
Security Target(AAMP7G SKPS)
Informal Security Policy Model
Descriptive Top Level AAMP7G Spec
Descriptive Low LevelAAMP7G Spec
ImplementationMachine Model
Formal SecurityPolicy Model
Development Process
Common Criteria
(VOL III: Assurance Rqmnts)
Evaluation Process
Assurance Plan
Trusted FacilitiesManual
ConfigurationManagement Plan
AbstractMachine Model
ArchitecturalDescription
Philosophy ofProtection Rpt
Covert ChannelAnalysis Rpt
Security FeaturesUser's Guide
CorrespondenceReport
CorrespondenceReport
AAMP7G SPKS FailSafe Design
Analysis (FSDA)
AAMP7G SPKS Sec'ty Verif. Tst(SV Plan, Procedure, Test, Rpt)
ValidationReport
NSA CertificationRqmnts (TSRD)
TEO
UIC
TOC
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
42
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.
43
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 areCross Domain Solutions
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
44
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.
AAMP7G ACL2 Formal Model
Integration with Eclipse AAMP7G
Tools
Disassembly
Process Stack
Console
ACL2 session
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
46
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.
47
An Object Code Verification Method – Compositional Cutpoint Technique
• 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
Entry
Exit
Cutpoint
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
48
Another Technique: Model-Based Development Verification
Dynamic simulations Automated static analysis
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.
Choose Start fromthe Simulation menuto run the simulation.
sf_car.mdl
Double-click toopen the GUI and select an
input maneuvervehicle mph
(yellow)& throttle %
transmission
Ne
gear
Nout
Ti
Tout
shift_logic
speed
up_th
down_th
gear
CALC_TH
engine RPM
VehicleUser Inputs
Brake
Throttle
Threshold Calculation
run() gear
throttle
down_th
up_th
Mux
Engine
Ti
throttle
Ne
impeller torque
output torque
transmission speed
vehiclespeed
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) {…
Automated code generation
Domain-specific graphical notation
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
49
SCADE
Lustre
NuSMV
PVSSafe StateMachines
SAL Symbolic Model Checker
SAL
Simulink Simulink
Gateway
StateFlow
Reactis ACL2
Prover
SimulinkGateway Design
Verifier
SAL Infinite Model Checker
SAL Bounded Model Checker
Rockwell Collins/U of Minnesota
MathWorks
SRI International
Reactive Systems
Esterel Technologies
Rockwell Collins Translation Framework
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
50
Testing vs. Verification – UAV Redundancy Manager
4
input_sel3
totalizer_cnt
2
persistence_cnt
1
failure_report
pc
trigger
input_a
input_b
input_c
DST_index
input_sel
triplex_input_selector
input_a
input_b
input_c
trip_lev el
persist_lim
MS
totalizer_lim
f ailreport
pc
tc
triplex_input_monitor
trip_level
trip_level1
totalizer_lim
persistence limit1
persist_lim
persistence limit
[DSTi]
[C]
[B]
[status_c]
[status_b]
[status_a]
[A]
[trigger]
[DSTi][MS]
[MS]
[DSTi][A]
[prev_sel]
[prev_sel]
[DSTi]
[trigger]
[trigger]
[status_c]
[status_b]
[status_a]
[A]
[A]
z
1
Unit Delay
IndexVector
[C]
[B]
[C]
[B]
[C]
[B]
f ailure_report
dst_index
Failure_Processing
mon_f ailure_report
status_a
status_b
status_c
prev _sel
input_a
input_b
input_c
f ailure_report
Failure_Isolation
Extract Bits u16[0 3]
DOC
Text
DST
Data StoreRead
8
dst_index
7
status_c
6
status_b
5
status_a
4
input_c
3
input_b
2
input_a
1
sync
failreport
sync<>
persistence_cnt<pc>trip_level
totalizer_cnt<tc>
persist_limResults• Spent 133 Hours Modeling Checking• Found 12 Errors• Nearly 200 hours of testing found no errorsFormal verification has found subtle errors that would likely be missed by
traditional testing.- Lockheed Martin
Subsystem/ Blocks
Charts / 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
Reset manager
6 / 31 2 / 26 / 0 1.32 * 1011 8
Totals 23 / 169 5 / 61 / 198 N/A 62
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
51
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
2
hr_val
1
lr_val
Switch2
Switch1
is_mode_low
is_mode_high
principal Id: SI
principal Id: UO
principal Id: SO
principal Id: UI
principal Id: UI
principal Id: SI
[lr_in]
Goto4
[hr_in]
Goto3
[lw_in]
Goto2
[hw_in]
Goto1
[lw_in]
From9
[hw_in]
From8
[lr_in]
From11
[hr_in]
From10
0
Constant1
0
Constant
hw_in
lw_in
hr_in
lr_in
mode_out
Buffer_Controller
State
hw_v al
lw_v al
Out1
Buffer
6
lr_in
5
hr_in
4
lw_val
3
lw_in
2
hw_val
1
hw_in
4
gry_IF_lr_val1
3
gry_IF_lr_val
2
hr_val
1
lr_val
-C-
UO_Principal
-C-
UI_Principal
Switch4
Switch3
Switch2
Switch1
-C-
SO_Principal
-C-
SI_Principal
OR
LogicalOperator1
OR
LogicalOperator
is_mode_high
is_mode_low
[UO_Principal]
Goto8
[SO_Principal]
Goto7
[UI_Principal]
Goto6
[SI_Principal]
Goto5
[lr_in]
Goto4
[hr_in]
Goto3
[lw_in]
Goto2
[hw_in]
Goto1
[lw_in]
From9
[hw_in]
From8
[UI_Principal]
From6
[SI_Principal]
From5
[UI_Principal]
From4
[SI_Principal]
From3
[UO_Principal]
From2
[lr_in]
From11
[hr_in]
From10
[SO_Principal]
From1
-C-
EMPTY1
-C-
EMPTY
0
Constant1
0
Constant
hw_in
lw_in
hr_in
lr_in
gry _IF_hw_in
gry _IF_lw_in
gry _IF_hr_in
gry _IF_lr_in
mode_out
gry _IF_mode_out
Buffer_Controller
State
hw_v al
lw_v al
gry _IF_State
gry _IF_hw_v al
gry _IF_lw_v al
Out1
gry _IF_Out1
Buffer
6
lr_in
5
hr_in
4
lw_val
3
lw_in
2
hw_val
1
hw_in
© Copyright 2008 Rockwell Collins, Inc. All rights reserved.
52
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 DO-
254, 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-to-
spec 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