200304 Gordon Uchenick

Safety Critical And Secure VxWorks: 

Safety Critical And Secure VxWorks Gordon M. Uchenick Aerospace Defense Specialist John Warther Aerospace Defense Industry Manager

Agenda: Three Significant Standards: 

Agenda: Three Significant Standards 1992: The Radio Technical commission for Aeronautics (RTCA) approves Document DO-178B, SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION 1997: ARINC, who sponsors the Airlines Electronic Engineering Committee, publishes Standard 653, AVIONICS APPLICATION SOFTWARE STANDARD INTERFACE 1998: The CSE (Canada), SCSSI (France), BSI (Germany), NLNCSA (Netherlands), CESG (UK), NIST (USA), and NSA (USA) jointly release Version 2.0 of THE COMMON CRITERIA FOR INFORMATION TECHNOLOGY SECURITY EVALUATION (aka “Common Criteria” or “CC”)

Tornado For DO-178B: 

Tornado For DO-178B

Ultra-fast DO-178B Overview: 

Ultra-fast DO-178B Overview Process oriented -- provides guidelines for the production of software for airborne systems Defines Software Levels Lowest is Level E: no effect on aircraft operational capability or pilot workload. Highest is Level A: catastrophic failure condition for the aircraft. Defines Objectives for software: Planning Development Verification Configuration Management Quality Assurance Certification

There Will Never Be A D0-178B RTOS: 

There Will Never Be A D0-178B RTOS Only complete systems are certified. A component of a system, like an RTOS, can’t be certified by itself.

Avionics COTS: 

Avionics COTS DO-178B Glossary Entry: Commercial off the shelf (COTS) software – Commercially available applications sold by vendors through public catalog listings. COTS software is not intended to be customized or enhanced. Contract-negotiated software developed for a specific application is not COTS software.”

Avionics COTS Problem?: 

Avionics COTS Problem? Still have to comply with DO-178B objectives But, generally: Certification material not available Prohibitive development costs Stifle innovation Options: Buy source code, develop certification material Buy consultancy services from vendor

“Service-based” Certification: 

“Service-based” Certification Drawbacks: True cost hidden Feature set not guaranteed Support Ownership of certification material unclear

Wind River’s Solution: 

Wind River’s Solution A true DO-178B COTS product, including: Certifiable multitasking RTOS Leading development tools Supporting DO-178B certification material

Beware of Vaporware! Level B Today!: 

Beware of Vaporware! Level B Today! Raytheon Wide Area Augmentation Flight Navigation System (WAAS) Safety critical: Uses VxWorks RTOS and Tornado for DO-178B development environment Expands # of GPS ranging signals to increase system availability Monitors GPS performance & increases accuracy

Level A Just About Complete: 

Level A Just About Complete Flight Management and Display system, customer can’t be disclosed

WindRiver DO-178B Process: 

WindRiver DO-178B Process Requirements Design Code Test Develop Tests Code exists - requirements re-engineered Requirements based tests Standard waterfall model

Updated Project Facility: 

Updated Project Facility

Product Packaging: 

Product Packaging Tornado/Cert VxWorks/Cert Tornado for DO-178B without docs Tornado for DO-178B with docs VxWorks Tornado/Cert VxWorks/Cert VxWorks Development Certification Certification Documentation Required to certify an application Source Code For VxWorks/Cert and tests Verification Tool / Results Coverage analysis tool and results

Certification Material: 

Certification Material Plan for software aspects of certification Software quality assurance plan Software configuration management plan Software development plan Software requirements standards Software design standards Software coding standards Software verification plan Software requirements specification Software design document Version description document Traceability matrix Software development folder Design reviews Code reviews Test reviews Functional tests Coverage results Tool qualification documentation Software accomplishment summary

Slide16: 

Certification documentation top-level menu browsed by Internet Explorer Hierarchical Navigation Frame

Slide17: 

Navigate to Requirements Navigate to requirement RR.6 for wind kernel services

Slide18: 

Sub- requirements Navigate to sub-requirement RR.6.4 for binary semaphores

Slide19: 

Navigate to sub-requirement RR.6.4.6 for binary semaphore give/take operations Sub-requirements

Slide20: 

Navigate to sub requirement RR.6.4.6-4 details Sub-requirements

Slide21: 

Navigate to test procedure for sub-requirement RR.6.4.6-4

Slide22: 

Test procedure for sub-requirement RR6.4.6-4 to test acquisition of a VxWorks/Cert binary semaphore when it is not available...

Slide23: 

….test program output statements….

Slide24: 

Navigate to requirement test procedure review

Slide25: 

Navigate to signed copy of review checklist…

Slide26: 

Review checklist…

Slide27: 

…including encrypted signature. Use Approve-It to verify.

Slide28: 

Binary semaphore library source code

Slide29: 

Binary semaphore library design description

Slide30: 

Code coverage results for binary semaphore library module, showing interleaved source code and assembler code… Analysis comment

VxWorks AE653/Cert: 

VxWorks AE653/Cert

VxWorks for High Integrity Systems: 

VxWorks for High Integrity Systems

Development of AE 653: 

Development of AE 653 AE653 leverages on the legacy of the past and provides a foundation for the future by use of existing Wind River products 95% of the runtime code came from already released products 2% of existing code was modified for new environment 3% of new code (mainly ARINC API) Combine features of VxWorks 5.5 with protection features of VxWorks AE Add in ARINC 653 layer Includes POSIX support, C++ and Ada capability (subsets) Provides temporal and spatial partitioning Extends VxWorks 5.5/AE to meet requirements of RTCA DO-178B A safe subset of VxWorks AE653 is created called VxWorks AE653/Cert FCS in January, 2003

AE653 Overall Architecture: 

AE653 Overall Architecture

AE653 OS Architecture: 

AE653 OS Architecture Partition OS System Objects ARINC Scheduler VxWorks AE Kernel AE Task Heap Application ARINC API Partition OS Core OS … ARINC PORT Global Msg Q Threads AE Task Heap Application POSIX API Partition OS AE Task Heap Native/Ada Application Partition OS System Calls Pseudo Interrupt

Deterministic Scheduler: AE653: 

Deterministic Scheduler: AE653 Partition scheduling using the ARINC-653 two-level scheduler

Time Management: 

Time Management Support for periodic and aperiodic processes; hard and soft deadlines Partition scheduling is transparent to the application TIMED_WAIT PERIODIC_WAIT GET_TIME REPLENISH

AE653 Core OS Description: 

AE653 Core OS Description Based on VxWorks AE 1.1 FCS RTOS Provides: Partition Management (Creation, Destruction, Scheduling, etc ) Partition boundary definition and enforcement (via MMU) Partition loading & debugging Trapping and execution of System Call on behalf of the Partition OS System resource allocation Manage I/O Drivers Message passing between partitions (IPC) Load and Holds Configuration records Debug agent (requested by the host tools) Manage the tasks that execute the partition OS Handles Interrupts (timers) and exception

Partition OS (vThreads): 

Partition OS (vThreads) Based on VxWorks 5.5 FCS Provides Application level OS capabilities: Threading (preemptive, priority based) System objects (Semaphores, Messages Queue, events, …) Heap Memory Management (Malloc/Free) Runtime libraries (ANSI, math, stdio, POSIX, …) Watch Dog All memory allocations are made within the partition space This insures space separation between partitions / applications All allocation are made at initialization time Interrupts and Exceptions are synthesized by the Core OS vThreads runs in user mode only

System Calls To The Core OS: 

System Calls To The Core OS Access to the Core OS is limited to few tightly controlled system calls Only 21 System Calls are needed by the Partition OS to execute Parameters are validated for each System Call Partial System Call List: SYSCALL_CONFIG_INFO_GET, /* get Partition Config Record */ SYSCALL_MSGQ_SEND, /* send msg to global msgQ */ SYSCALL_MSGQ_RECV, /* receive msg from global msgQ */ SYSCALL_MSGQ_OPEN, /* create/attach a globak msgQ */ SYSCALL_IO_OPEN, /* Open a file descriptor */ SYSCALL_IO_CLOSE, /* Close a file descriptor */ SYSCALL_IO_READ, /* Read from a file descriptor */ SYSCALL_IO_WRITE, /* Write to a file descriptor */ SYSCALL_IO_IOCTL, /* ioctl on a file descriptor */ SYSCALL_IO_CREAT, /* create a new file descriptor */ SYSCALL_IO_REMOVE, /* remove a file descriptor */ SYSCALL_IO_DEVICE_FIND, /* find an IO device */ SYSCALL_NEXT_EVENT_GET, /* Dequeue next partition event */

Synthesized Interrupt and Exception : 

Synthesized Interrupt and Exception External events (interrupt, exception) are communicated to the Partition OS in a synthesized form Core OS sends a signal to the Partition OS to notify that an external event happen 4 Event types supported: Clock Tick Delivers one or more clock ticks to vThreads. Synchronous Exception Partition code generated a hardware exception System Call Complete A blocking system call has completed Restart The Core OS wants to restart the Partition

Inter Partition Communication: 

Inter Partition Communication Ports are inter-partition mechanisms as defined by ARINC Available for ARINC and POSIX applications There are two kinds of ports Sampling Ports Timestamped No Guaranteed Delivery Unread messages overwritten Think “UDP” Queuing port Guaranteed Delivery Unread messages queued Think “TCP”

Application Environment Available to Developers: 

Application Environment Available to Developers 3 APIs are available to the application developer: ARINC 653 API POSIX API Partition OS API (vThread) The partition OS API will always be available to application developers The ARINC653 and POSIX API are optional Support for Ada Development

Application Environment Available to Developers: 

Application Environment Available to Developers Developing applications at the partition level is equivalent to develop an application on top of VxWorks 5.x RTOS with the exception of: Application are executed at user mode level Arinc653 Port or Global Message Queue API are used for inter-partition communication

Tornado Tools Environment: 

Tornado Tools Environment

VxWorks Simulator: 

VxWorks Simulator

Wind Shell: 

Wind Shell C interpreter shell provides interactive means for accessing and manipulating ARINC, POSIX, and/or VxWorks objects in system Supports script-based input, useful for automated initialization, configuration and testing Target-based shell can also be configured into VxWorks kernelfor direct access via serial console

Debugger Control: 

Debugger Control Provides system-level control from multiple debugging sessions Debug control for individual partitions ARINC partitions: all processes within a single partition are stopped together VxWorks & POSIX partitions: tasks can be stopped/started individually

Debugger: 

Debugger Multi-task language-level debugger Supports ELF compiler format output generated by GNU C compiler Display modes: C source code Assembler Mixed C source & assembler Breakpoints: Task-specific breakpoint Global breakpoint within partition Conditional breakpoints Display windows: Calling stack local memory global memory processor registers, etc. Debug over target connection: Ethernet, serial, BDM/JTAG, etc.

WindView 4.0: 

WindView 4.0 Display of ARINC processes, POSIX threads, Ada tasks and VxWorks tasks Triggering to isolate of areas of interest Data logging which can be triggered to focus on events of interest Detailed graphical displays of the timing of system Open API Patented software ‘logic analyzer’ or ‘run-time analyzer’ for multitasking applications. It provides a high precision graphical view of contexts of execution, and interrupts in your application, shown across time, aiding detection and aids diagnosis of real-time programming errors. WindView features include:

Slide51: 

vThread running within partition Posix Timer Functions Partition OS Thread of execution

AE653 Inspector: 

AE653 Inspector In a partitioned system, object ownership and OS object relations are key to understanding system operation New Object Browser provides clarity of relationships, ownerships and values All views can be dynamically updated Includes display of Posix and ARINC objects (Blackboards, Ports, Tasks, Events)

AE653 Inspector Detail: 

AE653 Inspector Detail

Security Roadmap: 

Security Roadmap

Wind River MILS/MLS Project History: 

Wind River MILS/MLS Project History Project Started – January 2002 Two Partner Companies and NSA Currently staffed 6 Full Time Engineers Additional Part Time Engineers as warranted Commitment from Wind River management to staff as necessary Current phase is Implementation

MILS/MLS Project Objectives: 

MILS/MLS Project Objectives Implement an NSA approved subset of the Technical Requirements, based on the Common Criteria that can support: MILS Separation Kernel MSL (Multiple Single Level) architecture MILS (Multiple Independent Level of Security) CORBA MLS (Multi-Level Secure) architecture Verify a specific subset of MLS technical requirements using rigorous testing methods and mathematical models Partner to bring a COTS solution to market Subject to acceleration based upon existing customer’s requirements

MILS/MLS Project Objectives (cont’d): 

MILS/MLS Project Objectives (cont’d) Utilize Common Criteria Initially focus on demonstrating a system that meets security functional requirements Target Requirements being developed will serve as the Protection Profile given that none currently exist for a deeply embedded system NSA has requested the Open Group to work on this with them Comply with EAL 5, 6, or 7

Customer Requirements: 

Customer Requirements Complete Ada and C development environment ARINC-653 Conformant Certifiable to DO-178B level A Certifiable to Common Criteria EAL 7 Architecture aligned with current Security Community thinking Provide a MILS environment Capable of supporting MSL and MLS environments Which can be built on top of MILS!

MLS Requirements: 

MLS Requirements Supervisor and user mode separation, supported by hardware (CPU) Application execution & data separation, supported by hardware (MMU) Partitions scheduled in a deterministic, independent manner (temporal separation) Access to kernel mechanisms that permit adaptation of an MLS architecture VxWorks AE/653 meets these “out of the can.”

DO-178B: CC Assurance Foundation: 

DO-178B: CC Assurance Foundation From “Towards Common Criteria Certification for DO-178B Compliant Airborne Software Systems, Executive Summary”, C. Taylor et. al., Center for Secure and Dependable Systems University of Idaho

Domain Isolation: Background: 

Domain Isolation: Background Monolithic Security Kernel Paradigm: The OS is completely responsible for security and makes it transparent (as much as possible) to the application. Application specific procedures find their way into the Trusted Computing Base (TCB). The TCB inevitably grows to contain the entire system. Eventually, adding one new procedure to the TCB consumes several man years just to update the Formal Methods. Completely reversing the architecture by making the application completely responsible for security also failed Causes very expensive duplication of effort for no security benefit. One system took so long to create and evaluate that by the time it was fielded it was obsolete

Domain Isolation: Current Thinking: 

Domain Isolation: Current Thinking Mathematically Assured Separation Kernel Software Decomposed into 3 Distinct Layers (John Rushby, PhD): The Micro Separation Kernel Middleware (file systems, networks, ORBs, etc.) The Application Kernel only insures DATA ISOLATION and enforces INFORMATION FLOW policy Middleware provides for reusable Application Component Creation and Secure Inter-Object Message Flow Applications provide their specific Security Functions (e.g., firewall, crypto) The only purpose of security at any layer is to enable the layer above it. Any security function is always implemented at the highest possible layer.

Domain Isolation: MASK: 

Domain Isolation: MASK User Mode Presented by Mark Vanfleet, NSA, at Open Group Security Forum, 7/25/2002

VxWorks AE653 Architecture: 

VxWorks AE653 Architecture Designer “partitions” the system into separate domains The scope of these domains is straightforward, similar to Unix process run in User mode Kernel domain memory is not accessible to tasks running in the application domains Application domain memory is not accessible to the kernel unless explicitly enabled

Secure VxWorks Possible Architecture: 

Secure VxWorks Possible Architecture AE653 Task AE653 Task Core OS Partition OS Partition OS AE653 Task VXWorks AE653 Kernel ARINC653 Scheduler System Partition ARINC API Driver API Application Application ARINC API Ada Runtime C Runtime POSIX API Ada Runtime C Runtime Ada Runtime C Runtime Partition OS ARINC PORT I/F ARINC HM I/F Mode Control I/F Board Support Package Device Driver I/F Heap Heap Heap Partition 1 Partition 2 Partition N Reference Monitor Policy Enforcement S E C U R I T Y A P P L I C A T I O N Reference Monitor has access to kernel mechanisms to enable Policy Enforcement. Policy enforcement will occur on data transferred between partitions (IPC) and external System I/O Mechanism for updating the Security Policy while the system is executing?

Security Certification Plan: 

Security Certification Plan Many of the security assurance requirements are met by the DO-178B process. Additional security assurance requirements will need to be added to this process to insure that documentation, audits, etc. are generated in the appropriate manner. This will need to be reviewed with NSA. When Common Criteria Testing Lab (CCTL) discussions begin, NSA will have to determine how the additional security related testing will be accomplished. This will require hardware assets and support.