>> I would like to add "pseudo-device cgd 4" [...]
> You may also want to add the lkm version of cgd [...]

Speaking of cgd....

Some time ago, I wrote my own encrypting disk layer, a la cgd.  But now
that I'm running something a bit more recent than 1.4T, I'd like to use
cgd instead, but it's lacking a couple of things my encrypting disk
does.  I'm going to add them, or something like them, but want to float
them here first; what I did may have problems, either theoretical or
implementation....

The first is, I'd like a way to have it prompt for the key on the
console, directly from the kernel.  This would amount to
pkcs5_pbkdf2/sha1, except with only the salt, or perhaps even nothing
(see below) provided by cgdconfig; the kernel would prompt for the
user-input portion.

The other is, I'd like a way to put root on cgd.  For my 1.4T+ version,
this was something like

options 	ED0_ROOT="\"wd0f\""

in the kernel config (I called mine ed), which makes it configure ed0
at autoconf time, with wd0f as the underlying device and
prompt-on-console key selection.  (It was soemwhat ugly to turn "wd0f"
into the underlying device, but I managed it.)  Mapping this to cgd
means supplying a little more information somehow, either hardwiring it
or elaborating the options.

The points which I consider essential here are that the disk contain
nothing in the clear except for bootblocks, kernel, and disklabel (in
particular, enough of a cleartext root filesystem to run userland
programs such as cgdconfig is not acceptable), and that the kernel not
contain the key (it would be acceptable for it to contain a salt).

These two features tend to go together, but, strictly, the dependency
is one-way.

Thoughts?  Any interest in seeing these in NetBSD's cgd?

/~\ 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