Transcript Safe and Protected Execution in Adaptive Architectures

Safe and Protected Execution in
Adaptive Architectures
Andrew A. Chien
Computer Science and Engineering
University of California, San Diego
Project Kickoff Meeting
November 5, 1998
Washington, D.C.
Challenges in Integrated Adaptive
Computing
• Integration with core system mechanisms enables
high performance
– Multiprocess environments fundamental, even for embedded
systems
– Errors in synthesis, hardware, software are common.
– How to build robust adaptive systems?
• Adaptation of core presents protection, validation,
and fault-containment challenges
– How to ensure process isolation?
– How to contain synthesis or hardware faults in the system
architecture?
– How to validate dynamic reconfiguration?
Static Adaptation and Protection
I/O Bus
Coprocessor
Host
Processor
M
SCSI
Gigabit
Ethernet
System bus
• Coprocessor: Host/OS based control or no protection
(coprocessor TLB, I/O TLB, direct physical access)
• Host Processor: ? (target of research)
• System Chip set: ? (target of research)
• I/O devices: ? (target of research)
• Everything (system in FPGA): all of the above
• => How to confine / validate the adaptation for safe and correct
execution?
Dynamic Adaptation
Coprocessor
Host
Processor
M
SCSI
Gigabit
Ethernet
Configurable
Wire and Logic
• Dynamic Reconfiguration challenges the basis of protection /
validation
– What the adaptive hardware can attach to and control? Modules,
internals?
– What checks / confines the actions of the dynamic adaptation?
– How to customize / generate the protection hardware to ensure
confinement?
– How to customize / generate the adaptive hardware to validate the
adaptation/synthesis/correctness?
Requirements for Safe and Protected
Execution
• Multiprocess Isolation
– system modularity for software (preserve)
– system modularity for software and reconfigurable hardware
• Offline Validation (testing)
– conventional hardware verification
– novel software / custom hardware validation
• Online Validation (error and fault detection)
– develop techniques for modular fault detection and containment
– develop techniques for design and synthesis of validation hardware
Process Isolation: Motivation
• Multiprocess protection is a fundamental modularity
element in software systems
–
–
–
–
Non-modular systems are not robust: MacOS, Win95, Win98, etc.
Software faults are not contained
Systems cannot be safely extended (restraining progress)
Failure modes here are: data corruption, fail passive, fail-stop the
machine
• Adaptive systems take this one level further
–
–
–
–
Software-software interactions
Software-adapted hardware interactions (sharing)
Adapted hardware - adapted hardware interactions (sharing)
=> how can we support flexibly extensible adaptable systems?
Examples
• Configurable hardware could allow one software
process to compromise
–
–
–
–
operating system data
other processes data
control registers within the CPU complex
control registers in I/O devices
• Configurable hardware itself could compromise
– all of the above
– other configurable hardware, even itself
– non-software visible state such as pipeline registers, pipelined bus
state, cache coherence logic, etc.
– low-level hardware capabilities (instruction sequence, bus
arbitration, etc.) => lock up the system!
Process Isolation
• Processes and reconfigured hardware must be
isolated to enable robust, extensible systems
• Goal: Develop an Architectural Framework for Safe
Adaptation
– Formalize OS notion of process and access control
– Identify control points in base and adaptive hardware for access
control
– Synthesize reverse maps for the OS protection constraints
– Example: privilege level control, control register access, address
generation, special instructions
Process Isolation Deliverables
• Axiomatic framework for safe and protected
execution in statically configurable hardware (HW,
OS)
– Enables proof of safety guarantees
• Base framework from conventional hardware
• Characterization of what reconfiguration can be
safely allowed within base axiomatic framework
• Extended framework which enables fuller
exploitation of reconfiguration
• Definition of reconfigurable “architecture classes”
based on provable safety guarantees
Progress
• Study of Base Framework (conventional systems)
• Study of Operating System (Irix) and Hardware Protection
mechanisms in the MIPS R10000
• Analysis of instruction set, operating systems protection mode
changes
– Conclusions for majority of RISC processors (designed for Unix style
protection structures)
– Some other operating systems/processors differ significantly
• Forms basis for formalizing conventional protection structure,
design of a protection structure for reconfigurable hardware
Instruction Set Features for Protection
• Modal Orientation
– Key processor state: CP0 registers
– Access controlled by special instructions which check processor mode
for execution
– Processor state reflects the CPU mode
– Unauthorized accesses are trapped and handled by a privileged
routine
• Privilege mode: Kernel, supervisor, user
– changes via: traps to privileged handlers which limit functionality and
entry points
– Base protection bootstrapped with special power-on traps and
bootstrap routines
• Instructions to Modify Protection Structures are Privileged
– processor state, segment registers, TLB entries
– control much of the access to the shared system data structures which
isolate processes
Operating System Usage
• Basic User/Supervisor Mode Distinction
– Supervisor mode allows modification of protection data structures
– Special instructions used to modify these data structures check for
privilege mode, trap otherwise
– Bootstrap to privilege mode, initial execution loophole must
correctly setup these data structures
• Most isolation is ensured indirectly through implicit
instruction execution constraints
– Address checking in the translation lookaside buffer
– Mode checking based on instruction type
– Simple mechanisms in hardware, all conventions in software
Initial Analysis
• Requirements/Observations for a Process Isolation Scheme
• Protection Axioms include
– Out of line implicit checking through modes, external units (e.g.
addressing)
– Complex schemes *not* used (e.g. protection rings, capabilities,
ACL’s, etc.) at the hardware level
• Nearly all of the hardware within a conventional processor
core is potentially configurable…
– novel operations, instructions, use of registers, datapath, caches, and
almost anything else
– Sensitive parts include the TLB/Address checking, a few choice bits of
machine state (e.g. privilege level), a few key instructions, and the
actual address bits which are sent to the rest of the machine.
• Writing document which describes axiomatic framework
and complete analysis
– Outlines architecture requirements for protected execution in the
presence of reconfigurable hardware
– First basis of useful distinctions (safe or not)
Online Validation: Motivation
• Classical system design depends on off-line
testing/validation of hardware designs
– Huge cost/ effort for complex designs, many errors get through
– CAD tools / Compilers often generate erroneous code (see errata
lists!)
– Correct by construction doesn’t work (at least not yet!).
• Adaptive systems inherently involve
– Unpredictable interactions (new hardware and software)
– Cross process interactions?
– Dynamic adaptation?
• Would you fly on an airplane with an adaptive
computer in the landing system?
Example: Online Validation
Logic Block 1
Logic Block 2
Logic Block +5=?
3
Logic Block 4
Version 1
Version 2
=
• Invariant checking
• Multi-version synthesis
• => detect errors, failures, etc. in static and dynamic
reconfiguration
Approach
• Invariant-based correctness checking
– Static annotation of invariants for test (exploit)
– Explore automatic derivation of invariants (essential for dynamic
adaptation)
– Constrained synthesis as a basic for generating hardware level
value invariants (analogous to dual-rail logic, parity techniques)
• Multi-version hardware synthesis
– Low-overhead hardware for validation (low assurance)
– High assurance hardware for validation (high overhead)
– Partial result checking (time or space division)
• Controlling cost of Online Validation
– Opportunistic exploitation of unused gates for partial redundancy
and validation
– Scalable techniques for partial space or time division multiplexing
• Systematic Evaluation and Measurement of
Effectiveness
Online Validation Deliverables
• Variety of Systematic techniques for Online
Validation of Reconfigurable systems
– Invariant and Multiversion synthesis
• Supporting Synthesis constraints and Architecture
structures for online validation (invariant
introduction, monitoring, and containment)
• Characterization of Cost and Effectiveness
– Cost: hardware, speed, and computation (synthesis) effort
– Effectiveness: coverage of errors and faults
Summary
• Develop and demonstrate architectures and
techniques for safe and protected execution in
statically and dynamically configurable systems
• Develop architectural classifications for
mechanisms which successively greater levels of
safety for both statically and dynamically
configurable systems
• => Understand the protection / validation
implications of design choices / features
• Design and evaluate a spectrum of techniques for
online validation in support of dynamic adaptation
• Demonstrate them on AMRM II prototype
hardware
Challenges
• How to perform experiments?
–
–
–
–
–
What are reasonable application workloads?
What are reasonable error models?
What are reasonable fault models?
What tools/vehicles are available for experiments?
What are good metrics?
• What constitutes a good design?
– Single architecture?
– Knowledge to design a set of architectures subject to application
and technology constraints rationally?
Bullets for Milestones and Timeline
• Yr 2: Axiomatic Framework for Flexible
Reconfiguration with Provable Safety Guarantees
• Yr 3: Demonstrated Synthesis and Invariant
Techniques for Online Validation with high
assurance
Fault Containment (just beginning)
• Develop an Architectural Framework for Fault
Containment
– Simple software, synthesis, and hardware fault models
– Exploit Process Isolation and Validation mechanisms for fast-fail
– Design hardware and software structures which enable
containment and reconfiguration
» Controlled synthesis and hardware mapping
» Synthesis of Hardware structures which provide
modularization
T3. Safe and Protected Execution
• Characterize Error / Fault models and their implications on the
AMRM Architecture
• Define a sound Protection architecture which enables safe use
of reconfigurability
–
–
–
–
process isolation
validation for runtime adaptation
integrated security mechanisms
match to traditional operating systems protection models