Safe and Protected Execution in Adaptive Architectures

1. Safe and Protected Execution in Adaptive Architectures Andrew A. Chien Computer Science and Engineering University of California, San Diego Project Kickoff Meeting November 5, 1998 Washington, D.C.

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

3. I/O Bus Coprocessor Host Processor SCSI Gigabit Ethernet System bus Static Adaptation and Protection • Coprocessor: Host/OS based control or no protection (coprocessor TLB, I/O TLB, direct physical access) • Host Processor: ? (target of research) • System Chip set: ? (target of research) • I/O devices: ? (target of research) • Everything (system in FPGA): all of the above • => How to confine / validate the adaptation for safe and correct execution? M

4. Coprocessor Host Processor SCSI Gigabit Ethernet Configurable Wire and Logic Dynamic Adaptation • Dynamic Reconfiguration challenges the basis of protection / validation • What the adaptive hardware can attach to and control? Modules, internals? • What checks / confines the actions of the dynamic adaptation? • How to customize / generate the protection hardware to ensure confinement? • How to customize / generate the adaptive hardware to validate the adaptation/synthesis/correctness? M

5. Requirements for Safe and Protected Execution • Multiprocess Isolation • system modularity for software (preserve) • system modularity for software and reconfigurable hardware • Offline Validation (testing) • conventional hardware verification • novel software / custom hardware validation • Online Validation (error and fault detection) • develop techniques for modular fault detection and containment • develop techniques for design and synthesis of validation hardware

6. 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) • Failure modes here are: data corruption, fail passive, fail-stop the machine • 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?

7. Examples • Configurable hardware could allow one software process to compromise • operating system data • other processes data • control registers within the CPU complex • control registers in I/O devices • Configurable hardware itself could compromise • all of the above • other configurable hardware, even itself • non-software visible state such as pipeline registers, pipelined bus state, cache coherence logic, etc. • low-level hardware capabilities (instruction sequence, bus arbitration, etc.) => lock up the system!

8. 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 • Example: privilege level control, control register access, address generation, special instructions

9. Process Isolation Deliverables • Axiomatic framework for safe and protected execution in statically configurable hardware (HW, OS) • Enables proof of safety guarantees • Base framework from conventional hardware • Characterization of what reconfiguration can be safely allowed within base axiomatic framework • Extended framework which enables fuller exploitation of reconfiguration • Definition of reconfigurable “architecture classes” based on provable safety guarantees

10. Progress • Study of Base Framework (conventional systems) • Study of Operating System (Irix) and Hardware Protection mechanisms in the MIPS R10000 • Analysis of instruction set, operating systems protection mode changes • Conclusions for majority of RISC processors (designed for Unix style protection structures) • Some other operating systems/processors differ significantly • Forms basis for formalizing conventional protection structure, design of a protection structure for reconfigurable hardware

11. 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 • Instructions to Modify Protection Structures are Privileged • processor state, segment registers, TLB entries • control much of the access to the shared system data structures which isolate processes

12. 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 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

13. Initial Analysis • Requirements/Observations for a Process Isolation Scheme • Protection Axioms include • 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… • novel operations, instructions, use of registers, datapath, caches, and almost anything else • Sensitive parts include the TLB/Address checking, a few choice bits of machine state (e.g. privilege level), a few key instructions, and the actual address bits which are sent to the rest of the machine. • Writing document which describes axiomatic framework and complete analysis • Outlines architecture requirements for protected execution in the presence of reconfigurable hardware • First basis of useful distinctions (safe or not)

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

15. Example: Online Validation • Invariant checking • Multi-version synthesis • => detect errors, failures, etc. in static and dynamic reconfiguration Version 1 Version 2 Logic Block 1 Logic Block 2 +5=? = Logic Block 3 Logic Block 4

16. Approach • Invariant-based correctness checking • Static annotation of invariants for test (exploit) • Explore automatic derivation of invariants (essential for dynamic adaptation) • Constrained synthesis as a basic for generating hardware level value invariants (analogous to dual-rail logic, parity techniques) • Multi-version hardware synthesis • Low-overhead hardware for validation (low assurance) • High assurance hardware for validation (high overhead) • Partial result checking (time or space division) • Controlling cost of Online Validation • Opportunistic exploitation of unused gates for partial redundancy and validation • Scalable techniques for partial space or time division multiplexing • Systematic Evaluation and Measurement of Effectiveness

17. Online Validation Deliverables • Variety of Systematic techniques for Online Validation of Reconfigurable systems • Invariant and Multiversion synthesis • Supporting Synthesis constraints and Architecture structures for online validation (invariant introduction, monitoring, and containment) • Characterization of Cost and Effectiveness • Cost: hardware, speed, and computation (synthesis) effort • Effectiveness: coverage of errors and faults

18. Summary • Develop and demonstrate architectures and techniques for safe and protected execution in statically and dynamically configurable systems • Develop architectural classifications for mechanisms which successively greater levels of safety for both statically and dynamically configurable systems • => Understand the protection / validation implications of design choices / features • Design and evaluate a spectrum of techniques for online validation in support of dynamic adaptation • Demonstrate them on AMRM II prototype hardware

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

21. Bullets for Milestones and Timeline • Yr 2: Axiomatic Framework for Flexible Reconfiguration with Provable Safety Guarantees • Yr 3: Demonstrated Synthesis and Invariant Techniques for Online Validation with high assurance

22. 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

23. T3. Safe and Protected Execution • Characterize Error / Fault models and their implications on the AMRM Architecture • Define a sound Protection architecture which enables safe use of reconfigurability • process isolation • validation for runtime adaptation • integrated security mechanisms • match to traditional operating systems protection models