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


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


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


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


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


6

DO-254 Supporting Processes

• Applied at each step

• Verification and Validation• Configuration Management• Process Assurance• Certification Liasion

– Typically via Designated Engineering Representatives (DERs)


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


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


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


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


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


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


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


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


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


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


17

High assurance, Deterministic, Hard

Real Time, Low power

RCI Microprocessor Technology


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


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.


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


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


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


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


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


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


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


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


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


29


(defthm gwv


(implies

(and




(current st2))


(select seg st2)))



ConclusionFunctionIndex


30


(defthm gwv


(implies

(and




(current st2))


(select seg st2)))



Hypothesis



31


(defthm gwv


(implies

(and




(current st2))


(select seg st2)))



Has also been formalized by

John Rushby in the logic of the

PVS theorem

Proving system

Hypothesis


DIA


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.


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


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


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


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


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


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


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


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”


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


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


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


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


AAMP7G ACL2 Formal Model

Integration with Eclipse AAMP7G

Tools

Disassembly

Process Stack

Console

ACL2 session


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


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


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


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


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


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


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

FMCAD 2008

Documents

Transcript of FMCAD 2008