In article <1009407732.13013.4.camel@janus.txd.hvrlab.org>, Herbert Valerio Riedel <hvr@hvrlab.org> wrote: >haven't tried myself, but at least with 2.4 kernels, there's the >pivot_root() system call, which should swap the root and making it >possible to unmount the ramdisk... When you do 'losetup ... /dev/loop /dev/bar' then mount something on /dev/loop, you cannot umount the filesystem containing /dev/loop until after you 'losetup -d /dev/loop'. If /dev/loop is mounted as root, you can't 'losetup -d /dev/loop' until after you're close to being finished running the kernel. Another problem with this initrd-can-do-everything theory is that in practice the damn thing breaks on every second kernel release. I've lost count of how many times I've encountered fatal kernel oopses when trying to initrd or pivot_root with a root RAMdisk that must be writable and cannot be freed when /linuxrc exits. A number of the 2.2.x kernels have made it out the door with initrd and RAMdisk memory management support sufficiently broken that the system crashes soon after boot, or can't even losetup at all. Strangely enough, initrd always works just well enough for Red Hat to load their SCSI driver modules. Hmmm... Sometimes when I'm running my laptop on a battery, miles from home, rebuilding my laptop's initrd with the help of a bootable rescue CD, I wonder if I'm the only person on the planet who actually _uses_ this crypto stuff. :-/ >I'd recommend taking a look at redhat's mkinitrd package, which contains >'nash', some kind of self-contained mini-shell, which includes the few >necessary commads usually used on initrd's... and add support to it for >getting a passphrase (+ hash it) and other encryption paramters...=20 Yes, the initrd can be made very small, but it still takes up 16K of RAM plus the code to implement RAMdisk and minix fs, and the extra bootloader configuration to load the RAMdisk, and some miscellaneous black magic to find the losetup utility and its runtime dependencies. It's more of an administrative headache than a size headache on modern machines, but the combined size of all of these components is still significant for a boot floppy or an older laptop. On the other hand, simply linking the important parts of losetup into the kernel takes up less than one K, and there are space savings in other places: the kernel-space losetup code can share cryptoapi's digest functions, initrd and minix FS can be dropped from the kernel image, and the kernel-space losetup code can go in an __init section to be discarded after use. There are none of the administrative headaches associated with extra cleartext partitions or initrd's (although your bootloader might need to specify ciphers, keysizes, and physical devices on the kernel command-line). We already have direct kernel support for root on various common non-physical-device cases including RAID, NFS, RAM disk, and separate boot/root floppies with a prompt to change media between them. These are all common and useful cases where direct kernel support is justified. I think root on cryptoloop support is a straightforward addition to those. -- Zygo Blaxell (Laptop) <zblaxell@feedme.hungrycats.org> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
