1. TIARA
Trust-management, Intrusion-tolerance, Accountability and Reconstitution Architecture
Howie Shrobe, Andre de Hon, Tom Knight

2. Outline For Meeting Review and progress on core ideas (30 minutes)
Upper level software (45 minutes)
Wrapper methods, method dispatch, method combination
Execution monitoring
Access control
Data tracing
System software (45 minutes)
Scheduler - Thread Manager
Device Driver and I/O system
Hardware design ideas (30 Minutes)
Next steps, discussion, and wrapup (30 minutes)

3. What’s Wrong Hardware Architectures provide “Raw Seething Bits”
Programming languages (C) provide direct access to “Raw Seething Bits” without manifest:
Identity
Boundaries
Invariant conditions
Unifying computational model and constraints
Anything important (e.g. the OS) must erect protection barriers to save itself from the “screaming ninnies”
This breaks modularity in the infrastructure
This interferes with introspection, adaptivity, etc.
Ultimately doesn’t provide right isolation

4. Origin of the Problem?
Good engineering tradeoffs based on 1970’s and 1980’s technology
Gates and memory were expensive
Challenge to build fast, capable systems
Minimalist designs ruled the day - RISC
Separate domains & context switch
Known to be expensive (10K-100K cycles)
System and software engineers know:
Must avoid crossing domains
Conclusion: Efficiency concerns require minimum compartmentalization
Single barrier between system and user code
System code runs with unlimited privilege
Single penetration gives away everything

5. TIARA Philosophy Memory and processor resources are abundant
Use them to provide guarantees:
Core system integrity
Access control
Accountability of results
Controlled sharing in an object oriented model
Everything lives in a common address space
Everything obeys overall memory conventions
Provide hardware supported metadata management
Everything carries rich metadata
Precise tainting of all data
Hardware enforcement of access control matrix
Provide support at many levels:
Hardware, middleware, application frameworks

6. TIARA Approach
Goal: Dramatically increase integrity, confidentiality, accountability of both system and user code
Without significantly sacrificing performance
Method: Add rich metadata to all runtime data structures
Metadata defines how data structures can be used
Spend modest hardware to process metadata in parallel with computation
Enforce proper data usage, information flow, compartmentalization
Structure: system code resides in many small compartments one for each conceptual usage
No single, all privileged component
Enforce structuring conventions to prevent and contain effects of common security breaches
Organizing Principle: Least Privilege & strong compartmentalization
Provide foundation for analysis and verification

7. TIARA’s Zero Kernal OS Operates on Structured, Object-Oriented Memory
Kernel functionality is partitioned into unitary components
Kernel components are isolated from one another and from user code using compartment meta-data
Each kernel component has the minimum privileges necessary for its task
Kernel components and user code are all in single uniform address space
System services are invoked via normal procedure calls without expensive context switch
Privilege carried in per thread process credential
All memory is viewed as consisting of Objects with Extent, Type, Identity, referenced only through Object-References, Object references are (nearly) immutable, Object references do not carry permissions, There are no raw pointers or pointer arithmetic, Reclamation is via Garbage Collection, No “Raw Seething Bits”

8. TIARA
Review of Core Ideas

9. TIARA Layers We are here Application Substrate: Data Accountability:
Hardware:
Security Tags Processing
Object Abstraction:
Structured Memory,
Method Dispatch
Operating System:
Hardware Management,
Hardware Level Policy
Meta-Object Level:
Wrapper Management
Access Control:
Policy Enforcement
System Software
Plan Level:
Self Monitoring and Recovery
Data Accountability:
Provenance Tracking
Application Substrate:
Application Data Management
Application Middleware
We are here

10. Objects, Metadata, Tags Step 2: Step 1: Step 3:
Location represents identity
Metadata is read into side cache at same time that object is read into cache
Metadata available when data is
Step 2:
Step 1:
Everything is an object.
Every object has manifest:
Type
Bounds
Identity
Meta-data is in object-header
Processor checks metadata while processing data
Unique ID
Data Cache
Bounds
Metadata
Meta Data Cache
Type
Slot-1
Slot-2
Data
Slot-n
Merge most important metadata with object-reference (or value of immediate data) as a “tag”
Avoid overhead of extra cache
Eliminate redundant representation of metadata
Process Tags and Data in Parallel
Step 3:
Data
Register File
Result Data
Tags
Unit
Operand 1
Operand 2
Instruction
Tag 1
Tag 2 PC
Result Tag
Trap Signal
Trap Dispatch Address
Tag A L U
Process Identifier
Tag-1
Data-1
Metadata not in tags
Tag-n
Data-n
Memory

11. Objects, Metadata, Tags Step 4: Step 5: Introduce richer metadata:
Every object lives in a “Compartment”
Any useful aggregation of data
Step 4:
Bounds
Type
Compartment
Slot-1
Slot-2
Slot-n
Data
Data Cache
Meta Data Cache
Metadata
Data
Register File
Result Data
Tags
Unit
Operand 1
Operand 2
Instruction
Tag 1
Tag 2 PC
Result Tag
Trap Signal
Trap Dispatch Address
Tag A L U
Process Identifier
Introduce Metadata for Threads
The “Principal” represents who the thread is working on behalf of at the moment
Held in processor register
Principals have limited rights to access specific data in specific ways
Step 5:
Tag-1
Data-1
Metadata not in tags
Tag-n
Data-n
Memory
Principal

12. Tags Data Path
Step 6:
Data
Register File
Result Data
Tags
Unit
Operand 1
Operand 2
Instruction
Tag 1
Tag 2 PC
Result Tag
Trap Signal
Trap Dispatch Address
Tag A L U
Process Identifier
Tag-1
Data-1
Metadata not in tags
Tag-n
Data-n
Memory
Principal
The tags data path determine if the operation is allowed and if so what the resulting tag is. It examines:
The tags of the operands
Data Type
Compartment
The principal
The instruction
This can be implemented in a Hash Execution (HashEx) unit whose contents are specified by the system software
Different data in the HashEx represents different access control and information flow policies
Compartment-1
Compartment-2
Compartment-3
Compartment-4
Compartment-5
Compartment-n
Principal-1 R RW
trap
trap
trap
trap
Principal-2
trap R R R
trap
trap
Principal-3 RW
trap
trap
trap RW
trap
trap
trap RW
trap
trap R
Principal-n

13. Tagged Data Path A L Data U Tags Tag Unit Register File Operand 1
Result Data
Tags
Unit
Operand 1
Operand 2
Instruction
Tag 1
Tag 2 PC
Result Tag
Trap Signal
Trap Dispatch Address
Tag A L U
Process Principal

14. The HASHEX Hardware = Register File ALU Hash RAM Program Counter
Result
Tag
Result Register
New PC
Trap Flag
Trap Vector Index
OP1 Tag
OP 2 Tag
PC Tag Op
Code
ALU
OP 1
OP 2
Register File
Address
Current Instruction OP R1 R2 R3
Instruction =
Hit?
Principal
Principal Register

15. Compartments & Principals
Lattice of Collections of Data
When combining data from 2 compartments results is in the LUB
Policy restricts flows between compartments
Principals:
Lattice of Roles a process may play
A process may switch Principal
Access rights granted to Principals on compartments
These imply flows that a principal can effect + =
Both Principals and Compartments have representations as objects in a compartment.

16. Tag Unit implements policy table on cycle-by-cycle basis
Compartment C1 C2 C3 C4 P1
R/W R -- W P2 P3
Principal
Can Principal P1 Load data in C1?
Can Principal P1 store data in C1 over data in C2?
Processor C1
Principal = P1
Memory
Memory C1 C2

17. Hardware provided support
Every word is tagged with meta-data
Every thread has an associated Principal
Principals are objects like any other
They have metadata that limit access to them
Compartments are objects
Instructions also have meta-data
All internal registers have meta-data
Including the PC
On every operation the combination of operand meta- data, PC meta-data, the Principal, the instruction and instruction meta-data are checked.
Every object reference is bounds checked

18. Summary Memory is treated as structured pool of objects
Base and Bounds
All references are bounds checked
No raw pointers
Every word carries meta-data
Data Type
Instruction, Immediate data, Reference
Compartment
Metadata can be encoded in a tag
Every thread has an associated Principal
Compartment
Base
Bounds
Type
Data
Example: 96 bit word
64 bits data
Base and Bounds for references
8 bits data type
16 bits compartment
8 bits for other use
Metadata Uses: Isolation between OS Data Compartments, Enforce OO model, Sandboxing, Multi Level Security (MLS), basic Integrity, Robust Error Handling, preventing Pointer abuse, Code bashing, buffer overflow, Policy enforcement, Auditing, Synchronization, etc.
Each Principal has limited (or no) rights to each compartment
These rights are checked on every instruction

19. TIARA
How these tools support our design philosophy: Rules that lead to least privilege, integrity and robustness

20. The Challenge
Our goal is to make the core system difficult to compromise and to limit the effect of any compromise that can happen
We’ve eliminated the traditional single, address- space boundary between OS and user code
Instead, we provide hardware support for a set of structuring rules (supplied by the system software designer) that hopefully limit information flows to those actually desired
Our goal is to show that we can design a reasonable OS that provides stronger protections than those provided by the conventional design
Structuring rules help establish abstractions that support analysis and verification

21. Rules: Data Structures
There are no raw pointers, only object references
Object references are created only by the memory allocator at the time an object is created
Object references are immutable
There are privileged retagging operations for special purposes
As a consequence, a thread can access an object only if:
It created the object
It has access to a second object which contains a reference to the first object
It is passed a reference to the object in a cross-thread call
All data accesses are bounds checked by the hardware

22. Rules: Reading
Hardware checks that the offset is within the object’s bounds
The Tags management unit (TMU) checks that the thread’s principal is allowed to read from the object’s compartment)
The Hash-Ex checks that the thread’s principal is allowed to load data from the compartment of the word in the specified slot of the object
Can Principal read from Compartment-O?
Can Principal load data in Compartment-S into a processor register?
Is Offset less than Bounds?
Principal
Slot-n
Compartment-S
Object-2
Offset
Bounds
Compartment-O

23. Rules: Writing
Hardware checks that the offset is within the object’s bounds
The HashEx checks that the thread’s principal is allowed to write data into object’s compartment
The Hash-Ex checks that the thread’s principal is allowed to overwrite the word in the specified slot of the object with data from the compartment of the write data (Compartment-W).
Can Principal read from Compartment-O?
Can Principal overwrite data in Compartment-S with data from Compartment-W?
Is Offset less than Bounds?
Principal
Slot-n
Compartment-S
Object-2
Offset
Bounds
Compartment-O
Write Data
Compartment-W

24. Data Structures Act Like A Lockbox=
Principal-1
Object-1
Compartment-1
compartment =
Slot-1
Compartment-2
Slot-2
An object’s compartment says which principals can look inside
The data inside have other compartments
You can safely pass arbitrary data between two threads by packing the data into an object whose compartment is only accessible to the principals of those threads
compartment
Slot-n
Object-2
Compartment-3
Compartment-n
compartment
compartment
Object-n is a string, this is it’s text.
Object-3
Object-n

25. Information Flow
Data can flow from compartment1 to compartmentn only if there is a sequence of principals P1, P2, … , Pn-1 and compartments C2, C3, …, Cn-1 such that each Pi can:
Read data from compartment Ci
Write data to compartment Ci+1
For any specific datum Dk in C1 these conditions may not suffice, since the thread may not have any way to obtain a reference to Dk …
Principal1
Principal2
Principaln-1
Compartment1
Compartment2
Compartment3
Compartmentn

26. Rules: Allocation & Reclamation
Memory is allocated only as well-formed objects
All sub-fields initialized with value, datatype, compartment
Typically with null value and null datatype
A thread can only allocate storage in compartments sanctioned by policy
Memory is only freed via garbage collection
No explicit “free” operation
An object’s memory is reclaimed when there are no remaining references to it
There are no dangling pointers
Meta data is immutable
Except for a few highly specialized system services
Consequence: There’s no way to “mint” or find a logically invalid reference to an object

27. Rules: Control Flow All instructions are contained in “code-objects”
A reference to a code-object is called a “procedure-reference”
This is normal reference with datatype, compartment, etc.
All branches are relative to the base of the code-object and are bounds checked
The only non-local transfer of control is via procedure call
Traps, throws, condition signaling and condition-handling are all performed via procedure calls
A call can only be performed on a procedure-reference
And only if the thread’s principal has procedure-call rights to the compartment of the code block
Returns are performed by calling a “continuation” passed as part of the call
A continuation is a just another code-block representing the rest of the procedure’s computation

28. Procedure Data Structures
Size
All branches are to an offset from the base of the current code-object and are bounds checked as are all accesses of an object
Principal
Call
Size
Trap?
HashEx
The call is allowed only if the Principal has procedure-call rights to compartment of Code-Object-2
Code-object-1
Branch
Procedure-reference
Reference
Meta-Data
Code-object-2

29. Closures HashEx Principali Principalj
A procedure call is actually performed on a “Closure”
Traditionally Closure = Code-object + Environment
We add a slot to closures for the Principal
If the principal is non-null, the called procedure runs with the new principal.
Closures are objects with metadata, including a compartment
This is the only way to change principal
A call is trapped if the current principal doesn’t have rights to call something in the compartment of the closure
Principal
Register
Principali
Principalj
Code Block
Environment
Principal
Environment
Continuation
Arg0
Arg1
Local 1
Return Values
Previous Frame
Call allowed only if principali has call rights to Compartmentk
Closure reference
for call
HashEx
Compartmentk
Closurem

30. Procedure Calls and Threads
Associated with every thread is a “process queue”
This is a queue of closures
There is a variant of the call instruction that makes a call between two separate threads
The call is not made immediately
The called closure is added to the process queue of the called thread
The instruction has both blocking and non-blocking variants
When the called thread completes the operation, it calls the return closure using a cross thread call to the calling thread (but doesn’t block)
Asks the scheduler to wakeup the original calling thread.
To avoid unintended information leakage the stack is compartmentalized

31. Compartmented Stack Structure
Caller
Callee
Callee R/W
Callee W
Caller R/W
Return Values
Local 1
Local 0
Return Values
Caller R/W
Local 1
Caller R
Local 0
Caller W
Callee R/W
Frame Pointer
Locals Pointer
Local Pointer
Arg1
Arg1
Arg0
Arg0
Continuation
Continuation
Previous Frame
Previous Frame

32. System Software How much “magic happens here” is in the design?
The system has a flat address space
There is no traditional memory barrier between OS components and user components
No additional overhead to OS calls
Must show that OS can’t be compromised
Must show that OS doesn’t create unintended information flows
File
System
Dynamic
Loader
I/O
Systems 
Memory
Allocation 
Virtual
Memory Manager
Device
Managers 
Garbage
Collector 
Scheduler and Thread Management 
Inter-thread
Communication 
Compartment and Principal Management
Control
Flow
Data Formats
Boot Loader  
HashEx Management
How much “magic happens here” is in the design?

33. Review of Known Exploits and Effectiveness of the TIARA Approach

34. Firefox Exploits
In a separate project we reviewed the documented attacks against Firefox version 1.0
Part of DARPA Application Communities project
There are over 100 categories of exploits
One Group, “Code Injection”, was examined for vulnerabilities within TIARA design
33 of original categories
6 sub-categories
TIARA would be impervious to all
Basic structuring conventions explain robustness

35. Firefox Exploits
Arb-code (91): The exploiter can execute arbitrary code on the user's machine.
Binary Code Injection (33)
Application Specific (6)
JS Privilege Escalation (41)
Spoof (11)
Destroy (2): The exploiter can destroy information (files) on the user's machine.
DOS (1): The exploiter can crash the application (Denial- of-Service)
Info (29): The exploiter can access some of the users information.
Often information related to other websites (logins, passwords, etc), but sometimes files on the users machine.
Not-security (4): The bug isn't related to security

36. Code Injection Exploits
stack-overflow (2): A buffer on the stack is overflowed.
Arbitrary code can be executed if the user can control the bytes that are written after the overflow.
The most common method is to overwrite the return pointer with a pointer to exploit code.
array-access (2): Binary code injection via out of bound array accesses (normally reads).
Arbitrary code can be executed if the memory accessed can be controlled by the user and virtual calls are executed on it.
heap-overflow (11): A buffer in the heap is overflowed.
dead-pointer (3): Pointers remain to memory that has been freed.
Arbitrary code can be executed if the memory can be controlled by the user and virtual calls are made through the dead pointers.
js-trampoline (2): The type of a javascript object passed to a system routine is not checked.
This allows the caller to pass in a different type of object (such as a dobuble) that can contain user controlled data where to pointer to the virtual table would be in a correctly typed object.
If a virtual call is ever made on the object in C++, arbitrary code can be executed (by placing the code in the heap in allocated JS objects).
js-gc (13): Java script garbage collection error.
This error results when a javascript writer can obtain a reference to an object that has been garbage collected.
Arbitrary data can be placed in the object (since it points to an active object of a different type).
The object can be exploited by calling a virtual function through it.

37. Code Injection Protections in Tiara
Stack overflow
Bounds & execution permission checks
Array access
Heap overflow
Dead pointers
Garbage collection and execution checks
JS trampolines
Data type & execution permission checks
JS GC
Garbage collection & type checks and execution permission checks
JS Privilege escalation
Principal transition checks

38. Summary
Operating system is structured as a set of independent, isolated, least privilege components
Using many system specific compartments, principals, data-types and instructions
Structuring rules provide strong limits on unintended control and information flows
These are the building blocks in the design of new style of operating system
Hardware enforces the rules
Examination of Firefox exploits shows that TIARA design is far more robust
Provides strong platform for high level abstraction infrastructure

39. Rest of What’s to come Overview of application substrate
More macroscopic use of metadata for access control
Information flow tracing
Execution monitoring
Core system software
Scheduler and thread management
I/O design and device drivers
Hardware micro-architectual ideas