Subject: Re: NetBSD & multiplicity
To: Kristaps Dzonsons <kristaps@kth.se>
From: Alistair Crooks <agc@pkgsrc.org>
List: tech-kern
Date: 12/29/2007 23:08:14
On Wed, Dec 26, 2007 at 02:28:03PM +0100, Kristaps Dzonsons wrote:
> Hello everybody, perhaps this may be of interest to you:
> 
>   http://mult.bsd.lv

This looks really interesting - thanks for pointing us to this.
 
> Essentially, it's a forked NetBSD-3.1 kernel that isolates resource
> contexts into "instances", allowing multiple (e.g.) non-conflicting
> init(8) process trees.  Jail machines are fun hacks, but don't have
> provable isolation and scatter cruft around the kernel.  This is another
> (I think more elegant) approach:
> 
> "Resource isolation is a strategy of multiplicity, the state of many
> isolated contexts within a single environment.  Isolated resource
> contexts have functionally non-isomorphic resource mappings: contexts
> with equivalent domain identities map to non-intersecting ranges in the
> resource co-domain.  Thus, in practise, if processes a and b return
> different values to an equivalent identity (say, for the hostname), then
> the callee context, for this identity, demonstrates resource
> non-isomorphism.  Although isolation is by no means a new study in
> operating systems, the BSD family offers few implementations, at this
> time limited to FreeBSD's Jail and the up-coming kauth(9) subsystem in
> NetBSD.  These systems provide frameworks with which one may orchestrate
> isolated environments by cross-checking and switching over credentials
> at the kernel's boundary.  In this document, we consider a radically
> different approach to resource isolation:  instead of isolating at the
> kernel boundary, we consider a strategy of collecting entire kernel
> sub-systems into contexts, effecting bottom-up resource isolation.  This
> document describes a work-in-progress, although a considerable
> implementation exists."
> 
> This has been under development for a few months and I now feel it's
> time to start getting feedback on the implementation.  It only has "soft
> resource" appropriation.  "Hard resource" appropriation is still
> underway; I want to save that until the soft resources are demonstrably
> stable.  If this interests you, then please, test and enjoy!  I'm
> looking to stabilise the "jail" concept while delving into network
> appropriation (which may either inherit from Zec's vimage approach or a
> straight-up ifalias).

Some basic feedback:

1. Very interesting. The website threw me for a while. Most of the
following is taken from reading the description of the screenshots,
and the screenshots themselves.

2. The concept seems to me akin to what are now known as Solaris
zones. Multiple instances of the operating system run.

3. I'm sorry, but I find the documentation inscrutable. Most of the
target audience for this know what an instance of an operating system
is, and how it relates to other forms of virtualisation.

4. The instance management, creation and destroying tools seem
completely unintuitive to me. Having said that, these are very
difficult things to get right, and are, to a certain extent,
very subjective. Perhaps cloning the Solaris tools would be a
good place to start?

5. Resource exhaustion in one instance would cause problems in
other instances - I assume this is the soft resource vs hard resource
that you talk about in the literature.

6. We usually fork development branches from HEAD. To save people
downloading the sources, I've put the raw mult diffs against 3.1 in

	ftp://ftp.netbsd.org/pub/NetBSD/misc/agc/mult/mult-devel0-raw.diff

and removed all the diffs with only RCS Id changes in

	ftp://ftp.netbsd.org/pub/NetBSD/misc/agc/mult/mult-devel0.diff

Neither of these diffs include the mult userland tools.

7. The <sys/inst.h> header file is a confusing name for me - I
keep thinking of sysinst whenever I see it.

These are minor quibbles, though, in the whole scheme of things, and
I think this is an excellent piece of work.

What are your plans for mult over the next few months? Do you have
some roadmap laid out which will show you where it's going? Would
you be interested in porting this to -current?

Many thanks,
Alistair