This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
• 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
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
• 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
• 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”
• 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
• 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
• 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
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
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) {…
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
• 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