HYDRA: The Kernel of a Multiprocessor Operating System

Wulf, et. al.

One-line summary: The bulk of this paper discusses the author’s design philosophies regarding how to build a flexible capability-based protection system for an operating system kernel.

Important points:

• Separation of mechanism from policy. OS Kernel should provide mechanism, not policy. Policy should be set by software components that run on top of the kernel, and policy can be implemented using the mechanisms provided by the OS kernel. This should guide what functionality should be added to the kernel vs. what should be left out. (Mechanisms should be included in the kernel, while policies should not.)
• Rejection of strict hierarchical layering. Authors argue that hierarchy limits flexibility. (More on this later…)
• Protection is central to OS. HYDRA makes significant use of capabilities to provide a security model much more flexible than traditional “hard-coded” read/write/execute privileges. Capabilities can ONLY be manipulated by the kernel. An object may have type-independent rights, and type-independent rights. Type-independent rights are “kernel-checked” rights (read/write/execute). Type-independent rights are “auxiliary/application-checked” rights; they can be checked for in capability templates in procedures. Hence, applications (collections of procedures) can assign their own semantics to these auxiliary capabilities.

What is an operating system supposed to do? Manage resources (both physical and virtual). HYDRA allows OS developers to define an object of a specified type for each resource the OS is expected to manage.

Authors expect HYDRA to be used as a core kernel, and for OS developers to potentially build multiple operating environments above it.

Three concepts core to HYDRA:

• Procedure: has a name, formal parameters, output(s), and a capability “template” for the formal parameters (check rights), “regular” rights, and a list of caller-independent capabilities. If actual parameter check rights match those expected by the template, then the procedure can execute with its “regular rights.” This allows the procedure to execute with extended rights without giving the caller any way to explicitly use those rights without calling the procedure.
• LNS (local name space): dynamic set of capabilities that a running procedure may use at run-time. Whenever a procedure CALL is made, a new LNS is created with the sum of the capabilities that the caller has, plus those that can be “derived” via the regular rights of the procedure. The LNS is part of the execution environment of the procedure, and is destroyed upon a RETURN.
• Process: smallest unit that can be scheduled for execution. a run-time stack of LNSes.

Protection = mechanism, Security = policy. HYDRA provides mechanism/protection. Higher-level OS components provide security.

Author’s believe the concept of “ownership” in an OS is vague, and not appropriate to implement security. Hence, there is no concept of “ownership” in HYDRA. In addition, they argue there is a better way to structure systems than for there to be a hierarchy of least trusted to most trusted components/users/etc. Inadequacy of the “ownership” model of system security is made apparent in a straightforward example presented in the paper. For example, just because a developer creates a program and “owns” it doesn’t mean that people who use the program are OK with that developer having access to databases that they create with the program. Capabilities are an elegant way of defining fine-grained protection tokens that can be checked for during different types of accesses for different objects.

Paper didn’t comment on how procedures should be “installed.” For example, if I write a procedure that has “regular” rights to access “everything” that procedure should only be able to be linked into the system by someone that has those types of rights.