FMCAD 2008 Considerations in the Design and Verification

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 Systems Commercial Systems • Precision Strike • Surface Solutions • Mobility & Rotary Wing • C 3 I • Air Transport • Business & Regional • Cabin Systems • e. Flight Engineering & Technology Advanced Technology Center © Copyright 2008 Rockwell Collins, Inc. All rights reserved. 2

High Assurance Systems DO-178 B (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 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. 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 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. 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 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 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 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 Correspondence. High-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

AAMP 7 G 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

AAMP 7 G Intrinsic Partitioning Verification • Allows multiple independent applications to execute concurrently on the same CPU • AAMP 7 G Enforces Process Isolation • “Separation Kernel in Hardware” • Ripe target 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

AAMP 7 G Design for Verification Characteristics • AAMP 7 G partitioning logic is (relatively) localized in the design • AAMP 7 G 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 ACL 2 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 ACL 2 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 theorem prover’s simplification strategies © Copyright 2008 Rockwell Collins, Inc. All rights reserved. 21

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

ACL 2 Syntax • Side-effect free – No global variables, all actions are explicit – A structure representing system state passed to and returned from most model functions • ACL 2 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 ACL 2 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 ACL 2 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 25

The GWV Formal Security Policy • GWV security policy developed for AAMP 7 G verification – Named after its authors: Greve (RCI), Wilding (RCI), and van. Fleet (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 P 1 – Kernel state cannot be influenced by K execution of code within partitions P 2 P 3 • Later generalized for a wider range of systems – GWVr 2, used to verify a commercial RTOS kernel P 1 K P 2 P 3 © 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 st 1))))) (implies (and (equal (select-list dia-segs st 1) (select-list dia-segs st 2)) (equal (current st 1) (current st 2)) (equal (select seg st 1) (select seg st 2))) (equal (select seg (next st 1)) (select seg (next st 2)))))) 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 st 1))))) (implies (and (equal (select-list dia-segs st 1) (select-list dia-segs st 2)) (equal (current st 1) (current st 2)) (equal (select seg st 1) (select seg st 2))) (equal (select seg (next st 1)) (select seg (next st 2)))))) 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 st 1))))) (implies Hypothesis (and (equal (select-list dia-segs st 1) (select-list dia-segs st 2)) (equal (current st 1) (current st 2)) (equal (select seg st 1) (select seg st 2))) (equal (select seg (next st 1)) (select seg (next st 2)))))) 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 st 1))))) (implies Hypothesis (and (equal (select-list dia-segs st 1) (select-list dia-segs st 2)) (equal (current st 1) (current st 2)) Has also been formalized by (equal (select seg st 1) John Rushby in the logic of (select seg st 2))) the PVS theorem (equal (select seg (next st 1)) Proving system (select seg (next st 2)))))) 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 H 1 L 1 H 3 L 1 L H 2 L 2 H 4 L 2 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

AAMP 7 G Formal Verification Common Criteria EAL 7 Proof Obligations Security Policy Formal Verification Abstract Model Formal Verification Low-Level Kernel Model Code-to-Spec Reviews Microcode AAMP 7 G © 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 secure state save partition load partition execute © Copyright 2008 Rockwell Collins, Inc. All rights reserved. 34

AAMP 7 G Detailed Formal Processing Model START STATE Partition Step Thread Context Switches Subroutine Invocations Basic. Blocks 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 INFO Reality – mapped into a single linear address space 0 xabcdef 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 ACL 2 library • Rules for resolving read/write operations – (read addr 1 (write addr 2 value ram)) = (read addr 1 ram) – (read addr 1 (write addr 1 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: 052 F (st. ie = nil) (Tx = (read 32 (vce_reg st) (VCE. VM_Number))) ; === ADDR: 0530 (st. Partition = Tx) ; === ADDR: 0531 (Time. Count = (read 32 (vce_reg st) (VCE. Time. Count))) ; === ADDR: 0532 (PSL[0]= Time. Count st) © Copyright 2008 Rockwell Collins, Inc. All rights reserved. ; -----------------------------------; === ADDR: 052 F A] CONT ; H] clear Interrupt. Enable, read VM number IE=0 T=BADDR. READ 32(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 Time. Count in VCE R=VCE. Time. Count W=RFB(VCE_REG) T=R+W ; L] read Time. Count T=BADDR. READ 32(T) ; 39

AAMP 7 G Verification Summary • Developed formal description of separation for uniprocessor, multipartition system • Modeled trusted AAMP 7 G microcode • Constructed machine-checked proof of separation on the AAMP 7 G model – ACL 2 theorem prover checked – Operations on pointer-laden, aliased data • Model subject of intensive code-to-spec review with AAMP 7 G microcode • Satisfied formal methods requirements for AAMP 7 G - certification awarded in May 2005 – AAMP 7 G 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

AAMP 7 G 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 (Vol. II: Functional Rqmnts) Formal Region UIC Protection Profile (Separation Kernel) TEO Security Target (AAMP 7 G SKPS) Assurance Plan Configuration Management Plan Formal Security Policy Model Informal Security Policy Model Correspondence Report Descriptive Top Level AAMP 7 G Spec Correspondence Report TOC AAMP 7 G SPKS Fail Safe Design Analysis (FSDA) AAMP 7 G SPKSSec'ty Verif. Tst (SV Plan, Procedure, Test, Rpt) © Copyright 2008 Rockwell Collins, Inc. All rights reserved. Abstract Machine Model Descriptive Low Level AAMP 7 G Spec Implementation Machine Model Validation Report 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 Do. D 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 ACL 2 – ~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

ACL 2 session Process Stack Disassembly Console © Copyright 2008 Rockwell Collins, Inc. All rights reserved. AAMP 7 G ACL 2 Formal Model Integration with Eclipse AAMP 7 G 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 automatic theorem proving technique for generating verification conditions from a small-step operational semantics, such as provided by the AAMP 7 G ACL 2 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 analyzed before implementation, then used to automatically generate implementation code or hardware and test cases. Domain-specific graphical notation if (Active. Standby_DWork. is_active_c 2_Active. Standby == 0) { Active. Standby_DWork. is_active_c 2_Active. Standby = 1 U; Active. Standby_enter_internal_c 2_Active. Standby(); } else { switch (Active. Standby_DWork. is_c 2_Active. Standby) { case Active. Standby_IN_Side 1 Failed: if (!Active. Standby_U. Side 1 Failed) { … Dynamic simulations © Copyright 2008 Rockwell Collins, Inc. All rights reserved. Automated static analysis Automated code generation 48

Rockwell Collins Translation Framework © Copyright 2008 Rockwell Collins, Inc. All rights reserved. 49

Testing vs. Verification – UAV Redundancy Manager Results • Spent 133 Hours Modeling Checking • Found 12 Errors • Nearly 200 hours of testing found no errors Formal verification has found subtle errors that would likely be missed by traditional testing. - Lockheed Martin © Copyright 2008 Rockwell Collins, Inc. All rights reserved. 50

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 © Copyright 2008 Rockwell Collins, Inc. All rights reserved. 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 DO 254, you are more likely to be able to successfully performal 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