Hello together, just like before the CRUX 2.5 release I packed together a test iso with support for an ecrypted root partition (on setup-time). I'd really like to get your feedback on this. Technically speaking there were not much changes that had to be done to the ISO repository, the diff [1] is really tiny. A new package named cryptsetup-initrd got added and its name makes its purpose quite obvious: it will enable you to build the required initial ram disk that allows the system to decrypt / during startup. I put the raw package [2] up for review, too. The test ISO [3] can be downloaded, too though I will upload a slightly fixed version tomorrow adressing a special use case mentioned in the /init script. To make your live easier I provide some documentation [4] covering the new parts for installation. The passphrase you have to provide your partition(s) could be provided via a USB-stick, too. This scenario is not yet covered by my documentation but I will add this, as soon as possible. Please let me know if you can think of any other ``authentication-scenario" that you would like to have added. There's only one issue left that may require discussion: when the boot process leaves initrd (switch_root /newroot) the real root's /dev directory is already mounted as tmpfs + populated but /sbin/start_udev calls ,---- [ head -2 /sbin/start_udev ] | # mount /dev as a tmpfs; note: some video drivers require exec access in /dev | /bin/mount -n -t tmpfs udev /dev -o exec,nosuid,mode=0755 | `---- so we end up with an (almost) empty /dev-directory. My idead was to check for the existence of /etc/.dev_populated (which would be creatd by our initrd before switch_root). If the file is available, start_udev should not (re)mount /dev but delete /etc/.dev_populated and continue execution after line #3. Currently this is not implemented so you'll have to comment out the command in /sbin/start_udev. Comments/Suggestions/critique is welcome! [1] https://serverop.de/~tek/crux-dmcrypt/ISO.DIFF [2] https://serverop.de/~tek/crux-dmcrypt/cryptsetup-initrd/ [3] https://serverop.de/~tek/crux-dmcrypt/crux-2.6-test0a.iso https://serverop.de/~tek/crux-dmcrypt/crux-2.6-test0a.iso.md5 [4] https://serverop.de/~tek/crux-dmcrypt/DM-CRYPT-STEPS kind regards, Thomas Penteker --
On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote:
Hello together,
Hello Thomas,
just like before the CRUX 2.5 release I packed together a test iso with support for an ecrypted root partition (on setup-time).
I'd really like to get your feedback on this.
First thanks for you work, but again you are very late with it, because we released an official 2.6-test1 already. Adding new features after that is something we should avoid.
Technically speaking there were not much changes that had to be done to the ISO repository, the diff [1] is really tiny.
Cryptsetup and dependencies should be added to packages.opt if we need them as packages on the ISO. Adding opt/popt to the ISO might create hidden problems, because other (core)ports will link against popt if installed. Currently our ISO bootstrap process can not prevent that, so we have to carefully check all packages after the bootstrap.
A new package named cryptsetup-initrd got added and its name makes its purpose quite obvious: it will enable you to build the required initial ram disk that allows the system to decrypt / during startup. I put the raw package [2] up for review, too.
I guess your final idea is to have a versioned tarball somewhere for download and not to provide the two binaries within the port? Do we really need a binary port at all? It should be possible to create cryptsetup-static in opt/cryptsetup? Is the busybox binary in any kind special for cryptsetup or can we use a new busybox port for that purpose? TBH I'm not convinced yet. I'd like to see a more general way/recipe for CRUX to switch to an initrd based startup as an alternative. This might be necessary for other things as well, e.g. I've heard that the kernel md-autodetect feature will be removed sometimes so you have to configure your raid with mdadmin at boot-time. best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
* Juergen Daubert (jue@jue.li) wrote:
On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote: (...) First thanks for you work, but again you are very late with it, because we released an official 2.6-test1 already. Adding new features after that is something we should avoid.
You are right, of course. My current working situation did not permit me to get this done earlier.
Cryptsetup and dependencies should be added to packages.opt if we need them as packages on the ISO. Adding opt/popt to the ISO might create hidden problems, because other (core)ports will link against popt if installed. Currently our ISO bootstrap process can not prevent that, so we have to carefully check all packages after the bootstrap.
That's true. Let me know if I can help out.
I guess your final idea is to have a versioned tarball somewhere for download and not to provide the two binaries within the port?
It'd save the user from going through (some) hassle, see below.
Do we really need a binary port at all? It should be possible to create cryptsetup-static in opt/cryptsetup? Is the busybox binary in any kind special for cryptsetup or can we use a new busybox port for that purpose?
It's not that easy to build it statically linked; libdevmapper needs to be linked statically for this, too, that's why I provided cryptsetup as a binary.
TBH I'm not convinced yet. I'd like to see a more general way/recipe for CRUX to switch to an initrd based startup as an alternative. This might be necessary for other things as well, e.g. I've heard that the kernel md-autodetect feature will be removed sometimes so you have to configure your raid with mdadmin at boot-time.
The initrd-generating process is straight forward. Coming up with a script to automate this should be quite easy, e.g.: gen-initrd mdadm cryptsetup would include the mdadmin binary (with the needed calls to it taken from /etc/initrd/mdadm.conf or similar) + the cryptsetup binary with the necessary calls. The details for the different modules could be included a) in the script b) in a directory /etc/ge-initrd/$MODULE possibility a) is not as flexible as b) but easier to implement. But I do see a certain complexity in b) because one would have to include some information about the order in which the commands would have to be executed (just like udev does). ps: what about the suggested check for /etc/.dev_populated in /sbin/start_udev? kind regards, Thomas Penteker --
On Thu, Aug 06, 2009 at 12:05:41AM +0200, Thomas Penteker wrote:
* Juergen Daubert (jue@jue.li) wrote:
On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote: (...) First thanks for you work, but again you are very late with it, because we released an official 2.6-test1 already. Adding new features after that is something we should avoid.
You are right, of course. My current working situation did not permit me to get this done earlier.
Cryptsetup and dependencies should be added to packages.opt if we need them as packages on the ISO. Adding opt/popt to the ISO might create hidden problems, because other (core)ports will link against popt if installed. Currently our ISO bootstrap process can not prevent that, so we have to carefully check all packages after the bootstrap.
That's true. Let me know if I can help out.
I guess your final idea is to have a versioned tarball somewhere for download and not to provide the two binaries within the port?
It'd save the user from going through (some) hassle, see below.
Sorry, I mean a tarball with at least the two big binaries busybox and cryptsetup in it. With your current solution ever user is forced to download them with ports -u.
Do we really need a binary port at all? It should be possible to create cryptsetup-static in opt/cryptsetup? Is the busybox binary in any kind special for cryptsetup or can we use a new busybox port for that purpose?
It's not that easy to build it statically linked; libdevmapper needs to be linked statically for this, too, that's why I provided cryptsetup as a binary.
Not a problem, having a static libdevmapper seem to be a good idea anyway. I'll commit an updated version of libdevmapper soon. best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
participants (2)
-
Juergen Daubert -
Thomas Penteker