>> The first is, I'd like a way to have it prompt for the key on the
>> console, directly from the kernel.

>> The other is, I'd like a way to put root on cgd.

> I assume the former is mostly as a prerequisite for the latter?

As a question of their history, yes.  Conceptually, no; I see
prompt-by-kernel as a way of hardening the system somewhat against
certain threats (such as a trojaned cgdconfig, or the risk of paging
out the page containing the key in some form).  Combined with a wscons
emulation that doesn't do colour and WSCOL_KERNEL_[BF]G, the colour of
the prompt (and echo) give some moderate level of user assurance that
the typed stuff really is going straight to the kernel, not to a
userland trojan.  (This is admittedly a matter of degree rather than
kind; kernels can be trojaned too.  It's just raising the bar.)

> Did you have any other particular reasons to want it for its own
> sake?

Only as an aesthetic/theoretical matter.  As a practical matter, the
only use I have for it at the moment is as used by root-on-cgd.

> As for root on cgd, are you aware of the init.root sysctl?

Um...no?  I couldn't find it in the 3.1 manpages, so I went poking
around in the -current source tree.  I can't find it in usr/src/sys/sys
or usr/src/sys/kern, nor in usr/src/sbin/sysctl/sysctl.8.  What is it
and where is it documented?  (And why isn't the answer "sysctl(8)"? :)

> This is intended to achieve essentially the same thing.  It's a
> feature of init, whereby you can run a few simple processes (like
> cgdconfig and mount) and then exit, and init will chroot to a
> specified directory and run rc as normal.  The effective result is
> that every user process ends up chrooted (ie, in your cgd).

A feature of...init??  Has sysctl been `improved' to the point that a
userland process can serve a sysctl tree?  (The `' are because I'm far
from sure I consider that an improvement.)

> If you combine this with a kernel that has the "real" root on an
> md(4), with the image embedded in the kernel, you have something
> essentially indistinguishable in practice from what you're after.

Well, once cgd grows the prompt-from-kernel - see below.

> The threat and trust model for the bootblocks and kernel is the same,
> just with a slightly larger kernel.  Put these on on a usb flash
> stick that you carry on your keyring separately,

That's not the sort of use I have in mind, actually; the use I have in
mind is for my laptop.  I don't like the idea of carrying data around
in the clear.  (I don't really *like* having even the bootblocks and
kernel in the clear, but *something* has to be.)

I dunno.  I don't like that sort of "boot a minimalist root and run
some userland, then switch to the _real_ root" setup, but I haven't
managed to pin down a basis for my dislike enough to say anything
useful about it.  It's certainly better from a "mechanism, not policy"
point of view, so I'm not sure what I dislike about it.  I'll have to
think about this.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B