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) • => 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 • => 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 • => 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, 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)

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

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 • => 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