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
Static Adaptation and Protection
M

• 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
• gt How to confine / validate the adaptation for
  safe and correct execution?

4
Dynamic Adaptation
M

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

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)
• gt 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.) gt 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, ACLs, 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
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?

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

16
Example Online Validation
Version 1
Version 2
Logic Block 1
Logic Block 2
5?

Logic Block 3
Logic Block 4

• Invariant checking
• Multi-version synthesis
• gt detect errors, failures, etc. in static and
  dynamic reconfiguration

17
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

18
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

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

20
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
• gt 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

21
(No Transcript)
22
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?

23
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

24
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

25
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

26
(No Transcript)