Supporting Security at the Gate Level:
Opportunities and Misconceptions
Tim Sherwood
UC Santa Barbara

Sketchy Assumption #1
• Anything that doesn’t 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

Doing it “right” today is expensive
• Boeing 787 has shared ARINC 629 bus
Passenger Network Flight Control Network
“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
Core Core
Predictors and
Hidden State • 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
Special Purpose
Logic / Interconnect
• The Ugly: System Complexity Growing o evaluation complexity growing dramatically o Architectures are working AGAIST us here

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?

Applications
Language
Compiler/OS
Instruction Set
Microarchitecture
Logic Gates
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

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
Information Flow
Hardware/Software
Design for Verifiable
Security
Microarchitecture
Logic Gates

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) passenger
• Technique for general lattice policies router
X avionics o e.g. Secret = High , Unclassified = Low

a b o a t b t
Formalizing Information Flow b a
• Automatically generate logic that tracks labels
• Tracking Logic is compositional o t
• 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.

a b s s o a b
Shadow Logic Composition s t a t a s s t b t b s o o t

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 clock test inputs
01
1011 stat e
1. Abstraction
Abstract Design clock abstract inputs
**
10 ** a a
2. Augmentation
Augmented Design labeled inputs
U U clock
*
* *
*
L L a L output
10 ** **
Specification of unknown bits
1
* U
T
Information flow lattice
1
U T
*
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: ???

Cross-University Laboratory for
Trustworthy Embedded Systems
Applications
Compiler/OS
Metodi , Aerospace
Irvine, NPS
Bultan, UCSB
Huffmire, NPS
Hardekopf, UCSB
Chong, UCSB
Sherwood, UCSB
Kastner, UCSD
Analysis
Verification
Language
Architecture Logic Gates

Thank you to the students!
• Ali Irturk, Bita Mazloom, Cynthia Irvine,
Dejun Mu, Hassan Wassel, Jason Oberg ,
Jonny Valamehr, Mohit Tiwari , Vineeth
Kashyap, Wei Hu, Xun Li , Ying Gao,
Varun Jain