The Sombrero Single Address Space Operating System

1
The Sombrero Single Address Space Operating
System

• Donald S. Miller
• Computer Science and Engineering Department
• Arizona State University

2
OUTLINE

• Review - Characteristics of a Single Address
  Space
• Advantages that can be supplied by a
  SASOS
• Sombrero Project Basic Premises
• Sombrero Key Features
• Sombrero Design Overview
• Basic Abstractions
• Hardware Design
• Software Protection Data Structures
• Operating System Structure and System
  Architecture
• Distributed System Design
• Support for Object-Oriented Programming and
  Design
• Sombrero vs. SASOSs built on stock RISC
  Processors - Opal Mungi
• Sombrero vs. other HW-Supported SASOSs - Monads
  AS/400
• Sombrero Prototype Status
• Sombrero-II Architecture
• Future Work
• Summary

3
Characteristics of a Single Address Space

• Virtual Addresses can be permanently and uniquely
  bound to all code and data objects
• VAs can serve as unique names
• VA space can serve as the only namespace
• The Virtual Address namespace spans all levels of
  the storage hierarchy on every node
• All Physical storage can be viewed as a hierarchy
  of caches for the contents of virtual addresses
• The Virtual Address namespace is manipulated
  directly by the CPU and access to it is
  controlled directly by memory and protection
  management hardware
• the CPU can directly enforce principal protection
  and resource allocation access policies on all
  objects defined in the system as it manipulates
  virtual addresses

4
Advantages that can be Provided by a SASOS

• Address translations remain the same for all
  programs
• Threads are free to travel throughout the VA
  space with no changes in the environment in which
  they are running in except for protection context
• Network-wide communication requires no prior or
  additional setup
• Internal pointers and pointers into other objects
  remain the same across all levels of storage and
  all programs
• marshalling, flattening and dynamic linking not
  needed
• Persistence without use of a separate file system
• Protection by restricting what a computation is
  allowed to access rather than what it is allowed
  to address
• managing IPC is reduced to managing protection

5
Advantages that can be Provided by a
SASOS(continued)

• SASOSs increase the available choices
• for structuring applications
• for structuring the operating system
• for sharing, protecting and storing data
• for communication between programs
• Fundamental Issue - how to structure an OS to
  provide
• a simple program development environment
• high performance
• in a system where conserving address space is no
  longer a driving concern

6

Donald S. Millerneed to color hat
SOMBRERO
7
Sombrero Project Basic Premises

• Economic and technological tradeoffs will
  increasingly favor single address space operation
  and SASOSs within ten years.
• It is necessary to make changes to CPU-resident
  protection and memory management hardware in
  order to design a SASOS that makes the paradigm
  shift viable.
• This hardware is feasible now and so is a SASOS
  built on it.

8
Sombrero - Key Features

• CPU-resident hardware protection
• provides a substrate for simpler/faster
  protection domain and object operations
• An open and extensible architecture that provides
  more choices for system structure
• Network-wide transparent distribution of the
  single address space
• Direct system level support for OOD and OOP
• No TLB required - can be replaced by a single
  CAM-resident inverted page table at the memory
  bus

9
Sombrero Design Overview

• Basic Abstractions
• Hardware Design
• Software Protection Data Structures
• Operating System Structure and System
  Architecture
• Distributed System Design
• Support for Object-Oriented Programming and Design

10
BASIC ABSTRACTIONS

• Memory Object ? Characterized by Range - a
  Distinct Variable Sized Contiguous Allocation of
  the Virtual Address Space - contains Memory
  Regions, sets of Virtual Addresses within a Range
  with Non-Overlapping Protection Attributes.
• Protection Domain ? Set of Memory Objects and
  Protection Domains Reachable by a Thread
  executing within it and their Associated Access
  Permissions. There are General and Carrier
  Protection Domains (GPDs and CPDs).
• GPD Code, Data and other GPDs accessible to all
  threads within it
• CPD Data and GPDs privately accessible to an
  Individual Thread
• Thread ? State of a Computation Represented by
  Current or most Relevant CPU Register State (PC,
  SP, General Registers, etc.), Reachable Carrier
  Protection Domain Memory and Status Information.
• Principal ? Unique Protected Identity that
  Represents a User or a System Service - binds
  Resources and Activities to an Owning User.

3/12/2016 21722 AM
ASU 64-bit OS Group
10
11
Sombrero Principals
12
HARDWARE DESIGNSombrero RPLBRange Protection
Lookaside Buffer

• Functional Requirements
• Logical Design
• RPLB VLSI Synthesis

13
FUNCTIONAL REQUIREMENTS

• Separation of Address Translation and Address
  Protection Functions
• Hardware Caching of Allowed Protection Domain
  Crossings
• Protection Domains for Threads Distinct from the
  General Protection Context
• Implicit Domain Crossing using Ordinary
  Instructions
• Protection for Variable Granularity Object Sizes

14
RPLB Logical Design

• Ranges and Regions
• Intra-Domain Operation
• Cross-Domain Operation
• The RPLB stores co-located protection triples
• ltAccessing PD, Accessed Resource, Access Rightsgt
• where the PD and resource are represented by VAs

15
RPLB LOGICAL DESIGN

• A Range is a contiguous set of VAs
• Unit of Protected Resource Access is Called a
  Region
• Possibly non-contiguous set of VAs within a Range
• Non-overlapping Protection Attributes from rwxs
• A Range Contains one or more Regions

• The RPLB Stores Region Definitions
• When Loaded with a Match Mask and a Dont Care
  Mask, Internal Combinational Logic Produces a
  Range Mask that Defines a Region
• The Figure shows the Definition of a Region
  consisting of
• 0C80H - 0CFFH and 0D80H - 0DFFH

16
RPLB Intra-Domain Operation

• On a Miss the RPLB is loaded with Protection
  Triples
• ltAccessing PD VA, Accessed Region VA, Access
  Rightsgt
• These are Compared with CPU Emitted Data On
  Every Memory Reference to Determine whether the
  Access is Allowed.

17
RPLB Cross-Domain Operation

• On a Miss the RPLB is loaded with Protection
  Triples
• ltAccessing PD, Accessed PD Entry Point VA,
  Switch Access Rightgt
• the New Protection Domain Virtual Address Name
  
• These are Compared with CPU Emitted Data On
  Every Non-Local Memory Reference to Determine
  whether the Entry is Allowed.
• For Allowed Accesses, the New GPD VA Name is
  Stored in the GPDBR and this is Followed by an
  Intra-Domain Access Attempt

18
RPLB VLSI Synthesis

• Proof of Concept - 1995
• VHDL Simulation
• Mentor Design Tools
• ASU ULSI Laboratory
• Performance Estimate-1997
• Mentor Autologic II Synthesis Tool
• Synopsis Design Compiler
• Cascade Design Automation Static Timing Analyzer
• Timing and Size Results
• Timing - 8-entry buffer
• single location - 500 MHz
• entire RPLB - 250 MHz
• Size - 1.27 mm2

RPLB Architecture Synthesized with Synopsis
Design Compiler Using 0.35-micron Library

• Conclusion
• -- 500 MHz Pipelined Design Feasible

19
Software Protection Data Structures

• Control Blocks
• Protection and Resource Access Lists (PRALs)
• Protection domain Access Lists (PALs)
• Resource Access Control Lists (RACLs)
• PRAL Simulation

20
Control Blocks

• Memory Object Control Block (MOCB)
• Protection Domain Control Block
• General PD Control Block (GCB)
• Carrier PD Control Block (TCB)
• Access Descriptor (AD)
• Principal Control Block (PCB)
• Token Tracking Structure

21
Protection and Resource Access Lists
PRALs contain the data needed to convert between
user policy information in the form of
principals, resources and access rights and the
CPU representation of these things in the form of
protection domains, virtual addresses and access
privileges.
22
Resource Access Control Lists
RACLs are classical Access Control Lists
23
Protection Domain Access Lists
PALs contain the same fundamental protection
information held by classical capability lists
24
PRAL Simulation

• Compared performance of Sombrero RPLB PRAL vs.
  Alpha NT TLB Page Tables
• Virtually everything had to be simulated
• Simulation Driver/RPLB/PRAL/TLB and Page Tables
• Parameters Number of Protection Domains
  (Threads) and Number and Size of Objects
• Results
• RPLB miss penalty on average 2 times TLB miss
  penalty
• RPLB miss rate lower than TLB miss rate for many
  common scenarios (e.g., objects greater than a
  page)
• RPLB performance roughly comparable to TLB
  performance and better for larger objects

25
Open and Extensible Architecture

• Peer-level modular system structure Executive
  provides a few basic services - user servers
  provide the rest. Operating system service
  methods can be overridden by user-defined
  function implementations.
• Communication between application programs, user
  servers and executive services via ordinary
  procedure call and return.
• OS services provided by instantiations of classes
  that are implemented directly as protection
  domains.
• Services can be passive ? significantly reduced
  IPC costs
• Pico-kernel (the CPUs protection domain) handles
  redirections caused by HW privilege mode changes
  and a very few hardware-related operations.
• Thread mobility and upcalls enable a cleaner
  separation of user policies and OS mechanisms

26
Sombrero Architecture
(a) Traditional View (b) Peer-Level Domain view
27
Open and Extensible Architecture(summary)

• The hardware in a HW-supported SASOS can make use
  of the properties of a single virtual address
  namespace to support common referencing between
  programs.
• This frees the OS of having to perform this time
  consuming operation at run-time and allows
  alternative system structures that provide more
  programmer-friendly ways to obtain system
  services.

28
Network-wide Transparent Distribution of the
Single Address Space

• Memory object, thread and protection domain
  migration supported by distributed surrogate
  kernel data structures enabled by tokens
• Transparent and implicit consistency and
  concurrency policy - every VA is tied to a
  specific policy
• Granularity of data transmission determined by
  policy
• Copy-set management uses local data/minimizes
  broadcasts
• Network routers use virtual addresses

29
Distributed Object Copy Set Management
Last Known Writer Graph
Pruning of Last Known Writer Graph
Pruning of Modified Page Cache Graph
Modified Page Cache Graph
CopySet Graph
30
Direct System Level Support for Object-Oriented
Design and Programming

• An object class can be implemented directly as a
  protection domain and a server as an
  instantiation of the class executive base
  classes can be extended via user overrides.
• Servers can be passive - exported service entry
  points invoke methods. These are accessed with
  ordinary procedure call instructions.
• Modular, peer level relationship between
  applications and user and system servers
• Hardware protection provides encapsulation.

31
Sombrero vs. SW- Supported SASOSs Opal and Mungi

• Centralized kernel-resident data structure for
  protection triples vs. capabilities
• Single inverted page table at the memory bus vs.
  multiple per-PD page tables
• Carrier protection domain vs. proxy/guard and
  PD-extension for domain crossings
• Direct support for object-oriented program
  development environment
• Implicit PD crossing at EVERY level

32
Sombrero vs. HW-Supported SASOSs AS/400 and
Monads

• Flat 64-bit address space - no segments
• No HW memory tagging or additional CPU
  instructions for capability and tag mgmt
• Network-wide single address namespace
• Single CAM-based inverted page table
• Simple extensible executive
• Availability of all single address space property
  advantages to applications

33
Sombrero Prototype Status

• Prototype being developed on two Alpha 21164
  boxes running NT
• NT Alpha PALCode modified to specialize an NT
  process to include full address range
• TLB misses outside normal address range forwarded
  to Sombrero extension of PALCode
• Emulated RPLB triggered by TLB misses
• Threads assigned to PDs within the specialized
  process
• NT provides basic I/O and file facilities
• First prototype, proof of concept and performance
  extrapolations expected before December 1998.

34
Sombrero II ArchitectureCompletely peer-level
system structure

• Kernel Services distributed among executive
  protection domains
• No central kernel and no hardware protected
  kernel mode
• A few Protection Domain Lock Registers name the
  protection domain that can access sensitive
  protected instructions and registers

35
Future Work(a.k.a. Things not completely worked
out yet)

• Implementation of a Universal Protection Domain
• needed to reduce RPLB entries
• Mini-System Call/Vectored Exception Mechanism for
  Sombrero II
• needed for high speed executive protection domain
  communication

36
Summary

• Advantages of a HW-Supported SASOS
• Improved program development environment
• Higher performance
• Better support for distributed applications
• A better match to the needs of real-time systems

CPU-resident protection hardware and a SASOS that
runs on it can be implemented now. This
combination makes fuller use of the properties of
a very large network-wide address space than
contemporary process-oriented systems for both
single node and distributed systems.
The Sombrero SASOS and Sombrero RPLB are Designed
to Meet these Objectives