From: Cem Paya 98 (Cem.Paya.98_at_Alum.Dartmouth.ORG)
Date: Mon Jan 12 2004 - 15:37:05 PST
Paper review: HYDRA, Kernel of a multi-processor operating
system
Corwin et. al.
CSE 551P, Cem Paya
This paper describes the design for a kernel flexible
enough to serve as the basis on multiple different
operating systems. (Unlike the van Horn paper, this more
recent work uses terminology such as “OS” consistent with
current usage.) Support for multi-processing is high
priority, since the system would be running on the
Carnegie-Mellon cmmp machine which supports up to 16
processors. This concession to hardware characteristics,
captured in the first of six requirements, is one of the
few places where the paper shows its vintage, as it is
otherwise ahead of its time. Second requirement addresses
one of the common gripes about OS design, confusing
mechanism with policy, and accidentally designing features
constraining the latter. Fourth requirement, rejecting
strict hierarchical layering is also interesting—and going
against Dijskta’s approach—but it is not clear how this
found expression in the final design because Hydra does
not look highly structured, and not all the collection of
loosely coupled small pieces this rejection would suggest
on the outset. Fifth requirement effectively embraces
capability based access controls, citing an earlier work
by Dennis, although van Horn semantics paper is referenced
as well. Focusing on hardware errors in the sixth
requirement is again something of an anachronism. With
manufacturing defects common and hardware reliability
relatively low, correctly handling fatal errors of this
type may have been relevant in the 1970s but is not a
significant concern today.
Armed with these six guiding principles, the authors go on
to describe a kernel implementing very flexible access
controls, granular down to the level of procedures. At the
foundation is a typed object system; every resource is
described by an object. Objects have types—which happens
to be just a pointer to one specific representative of
that class; this simple typing system allows user defined
types. Capabilities are analogous to pointers or
references to objects, but they also encode permissions.
(This is the important part—authors correctly point out
that knowing the name of an object is not sufficient for
granting access.) Procedure call builds on the C-list
idea in MCS paper by describing an explicit arrangement
where calling conventions are designed to alter
capabilities in a predictable way. Each invocation of a
procedure is associated with a local name space or LNS.
Each LNS is given capabilities that are a combination of
built-in ones associated with the procedure plus derived
from capabilities of the caller.
The risk model is not explicitly outlined in the paper,
but it appears to envision untrusted callers calling
trusted code. Such callers are only given permissions to
carry out the required logic set forth in the procedure,
during the invocation of the procedure. They do not retain
those capabilities afterwards for their own use. In
principle this seems like a good idea but experience
designing systems have shown that:
1. Callers find ways to manipulate the procedure into
doing things they were not mean to do—effectively use the
procedure as an oracle for doing computations the caller
was supposedly prohibited from performing. Bugtraq
archives are full of such classic set-user-ID priviledge
escalation attacks in UNIX.
2. Often times callees are untrusted too. Many
systems today use callbacks where applications call into
user code. The called procedure acquiring all of the
capabilities of the caller is just as dangerous.
Last section describes an example of a bibliography
system, with a series of complex access control
requirements and how these would be naturally implemented
in Hydra by extending the type system and defining new
capabilities of operating on the bibliographic collection.
However the argument most systems can’t implement such
complicated rules is unconvincing. While the fineprint
that “esoteric multi-file structures” can solve the
problem, this too is unnecessary: off-the-shelf operating
systems circa 1990 could implement this in multiple
different ways.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 15:37:10 PST