NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

root-on-cgd revisited


   Some background: I used to use an encrypted root when I was running
NetBSD/i386 4.0. Then I upgraded to an "amd64"-system, and the
root-on-cgd wouldn't work any longer. See PR 36963
( The
method I was using was to boot to a memory disk based file system, and
use sysctl init.root to switch root after cgd had been configured on top
of wd0a.

   I started a discussion on the PR a while back, one dev pointed out
that he didn't really put too much faith into root switching. I took
that as a challenge to figure out another way to do it, which wouldn't
require switching root.

   The obvious way to do it, I thought, is simply to specify a cgd
device as a root device in the kernel configuration. But that would
require cgd to be configured for the root device prior to root being
mounted. And so my project of getting the kernel to be able to configure
a cgd-device prior to root being mounted was born.

   The goal is to be able to specify the cgd parameters for the root
device in the kernel congfiguration or (as suggested by tls) in
boot.cfg. This way, we could get root-on-cgd support in the GENERIC
kernel, and implementing root-on-cgd support in sysinstall would be trivial.

   However, I was recently recommended to reevaluate my descision on
adding specific kernel support for "root-on-cgd". Another dev believes
that the init.root method is the better way to do it, and that it would
be better to put effort into fixing the above mentioned PR. And he
argued that the "easiness" of the kernelized solution can be achieved
with new tools.

   I would like a discussion on this. Essentially I want to know if I'm
wasting my time. If my patches would never make it into the netbsd tree,
I see little point in continuing on my project.

   My reasons for preferring specific kernel support:

   - I simply don't like the root switching. I found it confusing when
it worked, and I found it even more confusing when it stopped working.
Hardly a solid technical argument, but it's still a factor which
currently makes me prioritize the kernelized solution over attempting to
fix the problem with init.root.
   - For the end user, the init.root solutions is more complex. Though
the argument that new tools would alleviate that is valid, I find that
the system is overall still more complex. Consider for instance if
there's a typo in the rc script (assuming users edit it by hand) in the
memory disk image.
   - With the init.root method, there's a memory disk permanently taking
up ram "in the background" which is doing me no good. Sure, it's just a
couple of MB, and it's a neat little shell I get out to if I shutdown
and drop into single user mode. But I never used that feature before,
and I'm certain I wouldn't use it now.
   - init.root will need to be fixed. Although this may seem like a
weird reason, considering I still need to finish the kernelized support.
But remember what I wrote above: I found init.root to be confusing, and
I Simply Don't Like It. I'd rather work on something which I do like,
rather on something which I don't like. Also, I'm fairly certain my
kernelized support (if it doesn't turn out to be impossible to do) will
be finished before the init.root problem is fixed.
   - I feel that the kernel solution is much more "natural" (to the end
user). You just set the root device to cgd0 in the kernel config, set up
the appropriate parameters for cgd0, and boot the kernel off a memory
stick or cd.
   - Adding root-on-cgd-support to sysinstall would be trivial.
   - No special memory disk kernel is required. Even the GENERIC one
would suffice. You only need to be able to specify the root device and
cgd parameters in boot.cfg.

   Arguments against specific kernel support:

   - Security issues. Asking the user for input directly in kernel code
is a bad idea. While I agree with this argument conceptually, a simple
password prompt is easy to get right. We're not going to echo any
characters even. There's no complicated readline:ish interface.
   - Requires changes to the kernel, whereas the init.root doesn't.
Well, that's not entirely true. The init.root method requires PR 36963
to be fixed.

   Arguments for the init.root solution:
   - There's a nifty shell you drop out to if you shut down to single
user mode, which can be used for maintenance.

   Also, I'd like to add two additional points:
   - I believe init.root should be fixed. Having the possibility to drop
out to a maintenance memory disk image is a neat idea, if you have use
for such a thing. But for me spending time trying to fix init.root won't
fix the other issues I have with it (as listed above).
   - I have no idea if my kernelized solution will work in the end. :)
 But I'm giving it a try.

   I could go into some more details on the kernelized root-on-cgd
support, in case anyone is interested. But it's pretty straigt forward.

   Am I overlooking something? Thoughts, opinions, ideas are welcome.

Kind regards,
Jan Danielsson

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index