Transcript Morph: Supporting Safe Architectural Adaptation

Morph: Supporting Safe
Architectural Adaptation
Andrew Chien, Jay Byun
AMRM Project Kickoff Meeting
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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 a late-binding adaptation?
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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)
• 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?
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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
– Isolation hardware
– Fault mapping to OS semantics (meaningful faults to software)
» Example: privilege level control, control register access, address
generation, special instructions
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
Progress
• Study of Operating System and Hardware Protection
mechanisms in the R4000 (w/ Jay Byun)
» Detailed study of the instruction set
» Detailed study of operating systems protection mode changes
» => conclusions for simple RISC processors (designed for Unix style
protection structures), other operating systems/processors differ
significantly
» Written report 5/11/98.
» Basis for formalization of current protection structure, basis for
design of a protection structure for adaptable hardware
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
ISA Features for Protection
(cont.)
• Instructions to modify protection data structures are privileged
» processor state, segment registers, TLB entries
» control much of the access to the shared system data structures
which isolate processes
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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 of the 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
Concurrent Systems Architecture Group
Morph 9/21/98
University of California, San Diego and
University of Illinois at Urbana-Champaign
Observations/Conclusions
• Requirements/Observations for a Process Isolation Scheme
» 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… more sensitive is the TLB/Address
checking, a few choice bits of machine state (e.g. privilege level)
and a few key instructions
– novel operations, instructions, use of registers, datapath, caches, and
anything else?
• Plans: Complete analysis and write an architecture
requirements / capabilities document for protected execution in
the presence of reconfigurable hardware
» Can we make all of the useful distinctions yet? (unclear)
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
Observations/Questions
(cont.)
• Modal architecture has limitations -- high ILP, fast
traps, can it last?
• What impact does object orientation have on the
likely protection granularity?
• What impact does multithreading have on this
analysis?
• Impact of speculation/prediction?
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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?
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
Validating Adaptation
• Idea: Exploit additional hardware (unused gates) for
additional redundancy and validation
» Increases system reliability without major resource cost
» High Level generation of Validation circuits; invariants,
complements, etc. (automatic and manual)
» Wide range of redundancy possible, validation can be partial
to multiple in time and versions
» Can detect and signal errors or failures
» => May be the only approach possible for dynamic
adaptation
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
Approach
• Explore multi-version hardware synthesis
» low-overhead hardware for validation
» high-overhead hardware for validation
• Invariants
» Explore automatic derivation of invariants
» Exploit hardware invariant annotations for test
» (still need automatic synthesis for dynamic adaptation)
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
Open Questions
• How to generate designs that are distinct and not
subject to the same algorithmic errors?
• How to automatically derive minimal / flexible
validation constraints from a hardware specification?
From a computation specification -- include the
software?
• How to perform hardware synthesis for validation with
maximum isolation and coverage?
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
Summary
• Develop a deep understanding of isolation and
compatibility issues.
• Devise a set of architectural classifications and
mechanisms which can enable process isolation and
validation
• Understand the protection / validation implications of
design choices / features
• Design a series of working systems which
demonstrate the robustness of these results in the
presence of errors
• Demonstrate them on prototype hardware (UCI?)
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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?
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign
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
Morph 9/21/98
Concurrent Systems Architecture Group
University of California, San Diego and
University of Illinois at Urbana-Champaign