Safe and Protected Execution in Adaptive Architectures Andrew A. Chien Computer Science and Engineering University of California, San Diego Project Kickoff.

Safe and Protected Execution in Safe and Protected Execution in Adaptive ArchitecturesAdaptive Architectures

Andrew A. ChienComputer Science and Engineering

University of California, San Diego

Project Kickoff Meeting

November 5, 1998

Washington, D.C.

Challenges in Integrated Adaptive Challenges in Integrated Adaptive ComputingComputing

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

Static Adaptation and ProtectionStatic 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?

SCSI

System bus

I/O Bus

HostProcessor

GigabitEthernet

Coprocessor

M

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

SCSI

HostProcessor

GigabitEthernet

Coprocessor

ConfigurableWire and Logic

M

Requirements for Safe and Protected Requirements for Safe and Protected ExecutionExecution

• 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

Process Isolation: MotivationProcess 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?

ExamplesExamples

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

Process IsolationProcess 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

Process Isolation DeliverablesProcess 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

ProgressProgress

• 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

Instruction Set Features for ProtectionInstruction 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

Operating System UsageOperating 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

Initial AnalysisInitial 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)

Online Validation: MotivationOnline 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?

Example: Online ValidationExample: Online Validation

• Invariant checking

• Multi-version synthesis

• => detect errors, failures, etc. in static and dynamic reconfiguration

Logic Block 1 Logic Block 2

Logic Block 3 Logic Block 4+5=?

Version 1 Version 2

=

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

Online Validation DeliverablesOnline 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

SummarySummary

• 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

ChallengesChallenges

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

Bullets for Milestones and TimelineBullets 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

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

T3. Safe and Protected ExecutionT3. 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