Hello, 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 (http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=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