3/31/99TIS Labs at Network Associates AMP Project Status Stephen Schwab TIS Labs at Network Associates March 31, 1999

3/31/99 TIS Labs at Network Associates

AMP Project Status

Stephen Schwab

TIS Labs at Network Associates

March 31, 1999


AMP Project

• AMP Overview

• Exokernel Techniques

• AMP Security Architecture

• Work Status


AMP Node OS Project

• Goals– Provide separation and controlled sharing between

EEs and flows on each Active Network node.

– Support multiple EEs

– Constrain the execution of Active Code to access those entities for which it has authorization

• Utilize techniques developed throughout the AN community for safely and securely importing Active Code

– Implement security mechanisms without compromising performance


Active Networks Framework

ExecutionEnvironments

Node OS

EE1EE1 EE2EE2 IPv6IPv6

MGMTEE

MGMTEE

STORAGECHANNELS

POLICYDATABASE

SECURITYENFORCEMENTENGINE

From Calvert, 1998


AMP Node OS Implementation

• Exploit new features of a radically different OS architecture: the MIT Exokernel

• Exokernels separate concerns:– control of resources kernel– management library OS

• Library OS located in address space with each application (in AMP, each EE)


xok

userspace

CAPS

SCHEDULERQUEUE

PACKET FILTER

EE EE

PAGE TABLES

SWT

POLICYDATABASE

FLOWS/CAPS

AMP System Architecture

FLOWS

TRANSMISSIONQUEUE


AMP Project

• AMP Overview



• Work Status


Exokernels• Key Concept -- Expose information

– Expose allocation decisions– Expose low-level names– Expose revocation

• By allowing applications to directly manage resources, exokernels eliminate the costs that are associated with the mismatch between specific requirements and a general purpose implementation


Xok/LibExos Architecture

xok

userspace

CAPS

SCHEDULERQUEUE

PACKET FILTER

PAGE TABLES

environment

libExos libExos

app app

SharedState


• Hierarchical Capabilities– Uniform resource protection mechanism

– Each Xok Environment has a ring of capabilities associated with it

Xok Features

1 2 5

1 2 5 1

ExtensibleTamper-proofExplicitly passed on syscallsC1 dominates C2

C1

C2


Restricted Languages

• Dynamic Packet Filter (DPF)– Allows environments to download functions

that are compiled into a native code function that makes the packet delivery decision

• Wakeup Predicates– Restricted expressions that allow an

environment to sleep until a condition holds

• Untrusted Deterministic Functions


AMP Project

• AMP Overview



• Work Status


2

AMP Security Architecture

KernelKernelResources

FlowCapabilities

...

Access DecisionObjects

...

...

Resource AccessControl Tables

...

Manager Validator

Security Writer (SWT)

1 6 7

3 4

5

Packets arriveand SWT isinvoked before code is executed in aflow of control

Flow / Thread ofExecution


Security Architecture

• Process credentials during flow creation– within the SWT (Node OS Interface)– create and manage capabilities – maintain a cache of previous security decisions

• Provide interface to coordinate with EEs – EE specific policy and enforcement

• Control primitive resource types: – CPU scheduling, memory, channels


Use of Existing Xok Techniques

• Hierarchical capability mechanism as basic hook for access control techniques

• Environment mechanisms as foundation for implementing EEs/flows

• Use of kernel modules for mappings between: flows, capabilities, resources, resource groups, ACLs


Use of Xok Techniques in Diagram

1. Dataflow of packets to SWT

2. SWT has broad powers of access/update to3: Flow/Capability Mapping

4: Resource/Group/ACL Mapping

5: ACL as Capability/Resource Mapping

6. Dispatch packet to proper flow

7. Flow accesses resources after access check using capability, mappings, and ACL


What is New in Diagram

• SWT: validator cache of credentials and capability previously computed by manager using policy and semantics of credentials

• Access Decision Object– New implementation of ACL– Requires clean interface to ACL module– May require extension of interface


What is Orthogonal to Xok

• Efficient implementation of access decision object

• Efficient interplay between validator and manager components of SWT

• Clever taxonomy of resources

• New crypto stuff for dynamic symmetric-cipher credentials in PKI


Control Facilities

• Demultiplexing Control Facility

• Scheduling Control Facility

• Transmission Control Facility

• Shared Memory Abstraction– namespace control facility


ANEP

Demultiplexing Control Facility


ANEP

ANEP ANTS1



ANEP

ANEP

ANEP

ANTS1

ANTS1 Flow 47

ACKFlowID = X



SWT

Capabilities

Filter Table

ANEP Validate

ANEP.ANTS.FLOW

EE = ANTS

INIT(ANTS)

Filter Capability

ANEP/IP

ANEP/UDP/IP


SWT

Capabilities

Filter Table

ANEP Validate

ANTS

EE = ANTS

INIT(ANTS)

EE Filter Capability

Filter Capability

ANEP/IP

ANEP/UDP/IP

ANTS1/ANEP...

Top-Level Flow

Capabilities

Top-Level

ANEP.ANTS.FLOW


SWT

Capabilities

Filter Table

ANEP Validate

ANTS

ANEP.ANTS.FLOW

EE = ANTS

INIT(ANTS)


Filter Capability

ANEP/IP

ANEP/UDP/IP

ANTS1/ANEP...

Top-Level Flow

A B

Capabilities

Top-Level

A B TL


SWT

Capabilities

Filter Table

ANEP Validate

ANTS

ANEP.ANTS.FLOW

EE = ANTS

INIT(ANTS)


Filter Capability

ANEP/IP

ANEP/UDP/IP

ANTS1/ANEP...

Top-Level Flow

A B

A1 A2

Capabilities

Top-Level

A B

A BA1 A2

TL

TL


Scheduling Control Facility

• Xok implements a round-robin queue of scheduled quanta

• SWT can restructure/reassign quanta in queue as needed to provide guarantees

• Environments are the scheduled entities

• Well-behaved environments can clean-up and gracefully yield the CPU


Scheduling in Xok

Scheduler Quantums

Attributes environment runnable flag wakeup predicate timer ticks in-revocationflag capability list

1. New QuantumSelected

2. Prologue Executedwithin Environment

3. Epilogue Executedat end of quantum slice

4. Executing Thread-- yield to a threador environment-- sleep until anevent occurs


Transmission Control Facility

• Original Xok implementation does not guard the transmit syscall

• Need to control– Bandwidth allocation– Requested latency bounds

• Strategy: migrate buffers from transmitting flows to control facility


Shared Memory Abstraction

• Need to implement some sort of namespace above the virtual memory/page table level

• Provide for storage of information that should be sharable between EEs

• Options– Linda-style tuple space– In-memory file system– Fully functional persistent file system


AMP Project

• AMP Overview



• Work Status


Work Completed

• Exokernel Security Overview Report

• PAN port to Exokernel– EE developed at M.I.T. to explore the limits of

AN performance– Written in C, defers security issues– Similar structure to ANTS

• Node OS Interface WG– First draft


Work-in-progress

• AMP Security Architecture Report– Draft version identifying security requirements

• PLAN/OCAML port to exokernel– Needed to support FBAR

• ANTS/KAFFE port to exokernel– Prelude to supporting TIS Labs SANP variant

which requires JDK 1.2 security functions

• Performance measurements


Work-in-progress (continued)

• DPF Control Facility

• Scheduler/Context Switching Experiments

• ABONE/ANETD startup activities– preliminary to AMP nodes on the ABONE

• Security Interoperability– credential formats, authorization granularity,

policy specification, EE/Node OS trust boundary


Upcoming Work

• AMP System Design Report– Need to finalize the security requirements and

interactions before addressing implementation

• SWT and Control Facility Implementation– Node OS Abstractions and Interface– Secure flow creation (authorizations translated

into granted capabilities protecting local resources)


Upcoming Work 2

• FBAR Team 6 Demo– Standing up FBAR on two distinct EEs– Definition of policy describing when and by

whom separate FBAR instances or users may share state produced by Active Code

– Translation of policy into mediation and enforcement by the AMP architecture


Exokernel Research

• www.pdos.lcs.mit.edu


Node OS Flow Hierarchy

NodeOS

Flow1 Flow2Flow2 Flow3Flow3

InChanOutChan

InChan

OutChanOutChanInChan

Flow4Flow4 FlowNFlowN

InChanOutChan OutChanInChan

MEMORY POOLTHREAD POOL

From Peterson, 1998


ANEP

Channels

• Abstraction for Network Resources– Generalizes Network I/O device to include:

• protocol stack (ANEP/UDP/IP/ETH)• demultiplexing binding (addresses/ports/flow)• other attributes (transmission limits, QoS)

– Anchored Channels for Input and Output– Cut-through Channels for fast processing of non-active packets

Networkinterface

Networkinterface

IP

UDP


Node OS Channels

EEEE

NodeOS

Userspace

NETWORK

InChannel OutChannel

CutChannel

Documents

3/31/99TIS Labs at Network Associates AMP Project Status Stephen Schwab TIS Labs at Network Associates March 31, 1999