Morph: Supporting Safe Architectural Adaptation

1
Morph Supporting Safe Architectural Adaptation

• Andrew Chien, Jay Byun
• AMRM Project Kickoff Meeting

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

3
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)
• gt how can we support flexibly extensible
  adaptable systems?

4
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

5
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
• gt 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

6
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

7
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

8
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
• gt 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

9
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, ACLs, 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)

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

11
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 doesnt 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?

12
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
• gt May be the only approach possible for dynamic
  adaptation

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

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

15
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?)

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

17
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