1 / 52

FMCAD 2008

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. Rockwell Collins.

joshua
Télécharger la présentation

FMCAD 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Rockwell Collins Provider of Communications and Aviation Electronics Systems for Commercial and Government Applications Worldwide • Government Systems • Precision Strike • Surface Solutions • Mobility & Rotary Wing • C3I • Commercial Systems • Air Transport • Business & Regional • Cabin Systems • eFlight Engineering & Technology Advanced Technology Center

  3. 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 High Assurance Systems 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 • 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

  10. Common Criteria Evaluation Assurance Levels • 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 ;-)

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

  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. Formal Security Policy End High-Level Model Low-Level Model Start Mapping Functions 2-Model Assurance Architecture Application (e.g. firewall) Use in Application Proof Proofs of Security Policy Correspondence Proofs

  16. Validating the Low-Level Model 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 ? =

  17. RCI Microprocessor Technology High assurance, Deterministic, Hard Real Time, Low power

  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. Hypothesis Conclusion 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)))) Proving this to be true will add a rewrite rule to the ACL2 session

  25. Y Y Y X X X Z Z Z 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

  26. P1 P1 K P2 K P3 P2 P3 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

  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 (currentst1))))) (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 (nextst1)) (select seg (nextst2)))))) Conclusion Function

  29. GWV Separation Theorem (defthm gwv (let ((dia-segs (intersection (dia seg)(get-segs (currentst1))))) (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 (nextst1)) (select seg (nextst2)))))) Index Conclusion Function

  30. GWV Separation Theorem (defthm gwv (let ((dia-segs (intersection (dia seg)(get-segs (currentst1))))) (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 (nextst1)) (select seg (nextst2)))))) Hypothesis Index Conclusion Function

  31. GWV Separation Theorem DIA (defthm gwv (let ((dia-segs (intersection (dia seg)(get-segs (currentst1))))) (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 (nextst1)) (select seg (nextst2)))))) Hypothesis Has also been formalized by John Rushby in the logic of the PVS theorem Proving system Index Conclusion Function

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

  33. Common CriteriaEAL7 Proof Obligations Security Policy Formal Verification Formal Verification Code-to-Spec Reviews AAMP7G Formal Verification Abstract Model Abstract Model Low-Level Model Low-Level Model Kernel Kernel Microcode Microcode AAMP7 AAMP7G

  34. Time step step step step secure state save partition load partition execute 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 Event

  35. START STATE Partition Step Thread Context Switches Subroutine Invocations BasicBlocks Abstract Instruction Steps Concrete Instruction Steps Abstract Microcode Steps Concrete Microcode Steps AAMP7G Detailed Formal Processing Model

  36. Key Issue: Data Structure Representation Reality – mapped into a single linear address space Programmer’s view -- “boxes and arrows” NODE NODE NODE 0xabcdef INFO INFO Clear that write of one part of data structure doesn’t affect read of another part Same read/write independence not so easy to establish when mapped to linear address space

  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. Code-to-Spec Review Sample Microcode Formal Model ;---------------------------------------------------------------------- ;=== 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) ; ;=== 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)

  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. NSA Certification Rqmnts (TSRD) Configuration Management Plan Informal Security Policy Model TEO TOC AAMP7G SPKS Fail Safe Design Analysis (FSDA) AAMP7G SPKS Sec'ty Verif . Tst (SV Plan, Procedure, Test, Rpt) AAMP7G Formal Verification: Only one part of the MILS certification evidence Evaluation Process Development Process Common Criteria (VOL III: Assurance Rqmnts) Common Criteria ( Vol II: Functional Rqmnts) Assurance Plan Formal Region Protection Profile UIC (Separation Kernel) Security Target Formal Security Policy Model (AAMP7G SKPS) Correspondence Report Architectural Abstract Descriptive Top Level Description Machine Model AAMP7G Spec Philosophy of Correspondence Protection Rpt Report Implementation Machine Model Descriptive Low Level Covert Channel AAMP7G Spec Analysis Rpt Security Features User's Guide Validation Report Trusted Facilities Manual

  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

  45. ACL2 session Process Stack Disassembly AAMP7G ACL2 Formal Model Integration with Eclipse AAMP7G Tools Console

  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 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 Cutpoint Exit

  48. 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. Domain-specific graphical notation 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 Another Technique: Model-Based Development Verification Automated static analysis Dynamic simulations

  49. Rockwell Collins Translation Framework

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

More Related