Download Hydra OS: Non-hierarchical Protection and Subsystem Design and more Slides Computer Numerical Control in PDF only on Docsity!
Arvind Krishnamurthy
Spring 2004
Hydra: Non-hierarchical Protection
Course Wrapup
Hydra
n Motivation was C.mmp multiprocessor project:
n First multiprocessor with 16 PDP-11 machines n Hydra is the OS designed for this system n Didn’t know what kind of functionality for parallel machines n Experiment with new kinds of “subsystems”
n Micro-Kernel system: minimal OS
n Have a small piece of code to coordinate subsystems n Most of the functionality moved to subsystems
n Lots of subsystems that run at user-level
n Debug them like normal user programs n Have several alternative for a subsystem running simultaneously
Overall Design of Hydra
n Subsystems: code and data (protected)
n Only the code in the subsystems can access the data
n Non-hierarchical protection
n What is required to support non-hierarchical protection?
n Seal objects: subsystems seal objects before passing it to other subsystems n To manipulate, return to subsystem, unseal
User Extensible Types & Capabilities
n Objects comprise of:
n Name: unique number n Type: the id of the type from which object was instantiated n Representation comprising of data and capabilities
n Capabilities:
n Object name n Permissions: what operations can be performed
Sample Interaction
n When a person logs in, he/she gets a capability list of
useful capabilities
Private C-list (^) Shared Library
Type Type
Create Type
Create template
Create New Type
n Creating type (called gizmo) and new procedures (twiddle)
that can operate on gizmo
Private C-list Shared Library
Type Type
Create Type
Create template
gizmo Type Twiddle
Page
Template
Restr. gizmo type
Making Inter-subsystem Call
n Pass an instance of gizmo object to twiddle procedure
n Kernel does the following using the template object:
n Checks whether object is indeed of gizmo type n Checks whether object has permissions to have twiddle be invoked on it n Amplifies rights for the object n Creates an LNS for the procedure call n Attaches LNS to the process’s LNS stack
Twiddle
Page
Template LNS
New capability to gizmo object
Hydra Analysis
n Four issues:
n Cost of subsystem calls n Persistent object store: n Disk I/O costs n Garbage collection costs n Kernel size n Applications: needed to demonstrate the need for different subsystems
Concrete Examples: Tenex
n Most popular system at universities before Unix (early 70’s)
n Thought to be very secure. To demonstrate it, created a
team to find loopholes. Gave them all the source code/doc
n In 48 hours, had every password in the system!
n Code for password check:
PasswordCheck(char *userPasswd)
for (i=0; i<8; i++) if (userPasswd[i] != realPasswd[i]) Goto error;
n Looks innocuous, like you’d have to try all combinations
Tenex (contd.)
n Problems arise because of the combination of the following
three design choices:
n Tenex used virtual memory n It had a system call for checking passwords n In addition, it didn’t make a copy of the user arguments on system calls
n How do you break into such a system?
Internet Worm
n 1988: a worm broke into thousands of computers over the internet n Apparently initiated by Robert Morris Jr.
n Three attacks: n Dictionary lookup n Sendmail: debug mode, if configured wrong, can let anybody log in n fingerd: “finger [email protected]” n fingerd didn’t check for length of string n Allocated a fixed size array for it on the stack
foo(char *s) { char buffer[200]; … strcpy(s, buffer); }
Self-replicating program
n Proposed by Ken Thompson in his Turing award lecture
n Bury trojan horse in binaries, so no evidence in the source
n Replicates itself to every Unix system in the world, and even to new Unixes on new platforms
n Two steps: n Make it possible (easy) n Hide it (tricky)
n Step 1: Modify login.c (code snippet A) If (name == “ken”) Don’t check password Log in as root
n Next step: hide change, so no one can see it
Self-replicating program (contd.)
n Step 5: replace snippet C with trigger
n Result: all of the intelligence is only in the binary and not in the source code!
n If you use binary to compile “login.c”, it will recognize trigger to emit backdoor
n If you use binary to compile the compiler, it will recognize trigger
n It will emit code in the generated binary to watch out for invocations when you are compiling “login.c” or the compiler itself
n Summary: can’t stop loopholes, can’t tell if it’s happened, can’t get rid of it!
Tony Hoare’s Turing Lecture
n Tony Hoare’s accomplishments:
n Quicksort! n Study of monitors n CSP language (communicating sequential processes) n Axiomatic semantics of programming languages
n Turing Award Lecture:
n Anecdotes on simplicity and system design n Successes: compiler for Algol on Elliot 503 n Failures: operating system (Mark II for Elliot 503) n Experiences from language design committee meetings
The Algol60 Story
n Hoare started as a programmer for Elliot Brothers n Implemented Shell sort and other fast routines n Designed a variant of Shell sort (which became quick sort) n Given the task of designing a new high level language
n In 1961, attended a course on Algol60 by Naur, Djikstra, Landin
n Was able to implement his sorting variant using recursion n Decided to use Algol60 as the high level language for their machines
n Designed and documented in Algol n Then coded in machine language by hand! n Using explicit stack for recursion n Started with a small subset, was able to add more features later
Language Implementation
n Some great ideas:
n Security: bounds checking! n Brevity of object code n Fast language features (such as procedure calls) n Single pass compiler (not so important in the current day)
Failure (contd.)
n Decided to focus on just the Algol60 compiler
n Revised delivery in 4 months n Delivered, but n Original compiler: compiled 1000 chars/second, new compiler: 2 chars/second! n Problem: thrashing n Within a week doubled it, and doubled it in another two weeks n Not improving fast enough, project had to be abandoned
n Recovery:
n Called a meeting to discuss the reasons: n Lack of machine time, unpredictable hardware etc., technical writing for documentation n Over-ambition – the second system effect? n Hoare realized that he shouldn’t let others do what he didn’t understand himself!
Final comments
n Simplicity: Simplicity is an absolute good, not a tradeoff!
n Easier to build/maintain, run faster, is cheaper n Forces against it: n “Complexity = Intelligence”, “more features (complexity) is good” n How to make things simpler? Creativity and design before coding
n Performance: make every line of code as fast as possible vs. selective tuning (much better) – only a few places where performance matters n Biggest gain is going from non-functional to functional! Then add new data structures/algorithms to make the system go faster
n Life as a CS person: n Computers are tools: need to understand applications n If demonstrating an idea/doing research: Go to the extreme! n Stay broad: Breadth helps depth n Technology is changing fast; exploit new changes/shifts n Breakthroughs occur when people cross traditional boundaries: compilers and architecture, graphics and VLSI, etc.; steal from other fields!
