Morph supporting safe architectural adaptation
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

Morph: Supporting Safe Architectural Adaptation PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on
  • Presentation posted in: General

Morph: Supporting Safe Architectural Adaptation. Andrew Chien, Jay Byun AMRM Project Kickoff Meeting. Challenges in Integrated Adaptive Computing. Integration with core system mechanisms enables high performance Multiprocess environments fundamental, even for embedded systems

Download Presentation

Morph: Supporting Safe Architectural Adaptation

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Morph supporting safe architectural adaptation

Morph: Supporting Safe Architectural Adaptation

Andrew Chien, Jay Byun

AMRM Project Kickoff Meeting


Challenges in integrated adaptive computing

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?


Process isolation motivation

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?


Process isolation

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


Progress

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


Instruction set features for protection

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


Isa features for protection cont

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


Operating system usage

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


Observations conclusions

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)


Observations questions cont

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?


Online validation motivation

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?


Validating adaptation

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


Approach

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)


Open questions

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?


Summary

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


Challenges

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?


Fault containment just beginning

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


  • Login