Sketchy Assumption #1 Anything that doesnt run x86, or an existing general purpose operating system, or allow the full generality of a systems we have today, is not important.
Software Everywhere critical infrastructure increasingly connected to the web (200,000 ICD/year in US alone) ability to run windows is not a bar for archiecture
Boeing 787 has shared ARINC 629 bus Flight Control Network Passenger Network Doing it right today is expensive The proposed architecture of the 787 […] allows new kinds of passenger connectivity to previously isolated data networks connected to systems that perform functions required for the safe operation of the airplane. Because of this new passenger connectivity, the proposed data network design and integration may result in security vulnerabilities from intentional or unintentional corruption of data and systems critical to the safety and maintenance of the airplane. FAA, 14 CFR Part 25 [Docket No. NM364] High-Assurance Systems need to be verifiably: Secure, Reliable, and Predictable
Assurance Evaluation Complexity RedHat Linux: Best Effort Safety (EAL 4+) o $30-$40 per LOC Integrity RTOS: Design for Formal Evaluation (EAL 6+) o $1,000 per LOC o More evaluation of process, not end artifact Need ways to understand the artifact o Lots of great work already here at the software layer o Why should hardware people get involved?
Hardware Scaling The Good: Processing Capabilities are Scaling o more cores / chip o faster performance through speculation, prediction, caching, parallelism o allows for deeper system integration, custom functionality, and more feature rich software to run everywhere The Bad: Increasingly Coupled Subsystems o predictors, caches, buffers, parallelism lead to complex timing variations and complicated definitions of correctness o systems are increasingly coupled The Ugly: System Complexity Growing o evaluation complexity growing dramatically o Architectures are working AGAIST us here Core Predictors and Hidden State Special Purpose Logic / Interconnect
Sketchy Assumption #2 All hardware is fully correct, it is software only that is the problem! Reality: o Definition of correct is hard. Any model of what the machines does is wrong ( ISA, simple models ) o Processors have bugs o How do we know what the effect of the hardware implementation will have on software properties?
Properties Cross Abstractions Security, Realtime, and Safety properties are a function of interactions across levels of abstraction make evaluation, debugging, optimization, and analysis very difficult Applications Language Logic Gates Microarchitecture Instruction Set Compiler/OS Security Properties
SketchyAssumption #3 Well, it is impossible to say anything about the system properties (including software) at the hardware level. Especially if there are bugs. Reality: o Hardware sits below all of the software system definition. o Provides a way to unify timing channels, implicit flows, explicit flows o Sound but not perfectly precise, you give things up due to the semantic gap o Basic science required!
Hardware Design for Software Security Verification Applications Language Logic Gates Microarchitecture Instruction Set Compiler/OS Security Properties Instr Mem +4 jump target R1 R2 through decode PC Predicate s Reg File old value Data Memory hig h low Lease Unit Timer PC Memory 0 1 0 1 timer expired? Restore PC Sound Information Flow Analysis Hardware/Software Design for Verifiable Security
Formalization of Information Flow Trusted vs. Untrusted Tasks o Trusted: processes which are critical to the correct functionality of the space vehicle systems o Untrusted: mission processes, diagnostics, anything whose malfunction will not cause a vehicle loss Enforce the property of non-interference: o Verify information never flows from high to low. o Untrusted information is never used to make critical (trusted) decisions nor to determine the schedule (real-time) Technique for general lattice policies o e.g. Secret = High, Unclassified = Low router X passenger avionics
Formalizing Information Flow ab o ba o b t t a t Automatically generate logic that tracks labels Tracking Logic is compositional Captures timing channels, and real time constraints Security Constraints can be expressed and hardware assertions Mohit Tiwari, Hassan Wassel, Bita Mazloom, Shashidhar Mysore, Frederic Chong, and Timothy Sherwood. Complete Information Flow Tracking from the Gates Up Proceedings of the 14th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), March 2009. Washington, DC Jason Oberg, Wei Hu, Ali Irturk, Mohit Tiwari, Timothy Sherwood and Ryan Kastner Theoretical Analysis of Gate Level Information Flow Tracking, Proceedings of the 47th Design Automation Conference (DAC), June 2010.
Shadow Logic Composition ba o s t o asa t t s bsb t t s a b s o
Sketchy Assumption #4 Look at all those gates! Gate level techniques will kill your performance and efficiency! Reality: o You only need hardware to help with dynamic checks. o This shadow hardware can be used for static analysis
GLIFT Verification Flow Digital Design 1011 clock test inputs stat e output 01 Specification of unknown bits 1. Abstraction 10 clock abstract inputs state abstract output ** a a a 10 state input ** * 1 Abstract Design 2. Augmentation 1 0 clock labeled inputs state labeled output * L L L T T U U * U U 1 U T * U T Information flow lattice Augmented Design This is analysis, what about design?
Brief History Rev 1: Provable properties (but miserable to program) Rev 2: Execution Leases Rev 3: Full prototype system (with partitionable caches, pipelining, IO, etc.) Rev 4: Multiprocessor with NoC Rev 5: ???