Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 Morph: Supporting Safe Architectural Adaptation Andrew Chien, Jay Byun AMRM Project Kickoff Meeting

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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 University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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)

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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)

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?)

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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?

Concurrent Systems Architecture Group University of California, San Diego and University of Illinois at Urbana-Champaign Morph 9/21/98 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