nslu2 encrypted root fs again
I have now done some more work with my precious slug.
As I have described briefly in an earlier thread, with a serial port
and an install procedure similar to the one described in
http://www.nslu2-linux.org/wiki/Debian/CreateAnEncryptedRootFilesystemWithLUKS
where the initramfs image is built with yaird, it is possible to get a
fully encrypted slug, both root and swap on LUKS encrypted partitions,
and using a serial console to enter the LUKS pass phrases.
I then realized that it may be possible to do the install without
yaird, which I have now done. My plan for this was again to use 2
separate USB-memories, one for an intermediate install and one for the
final encrypted install.
1) Do an intermediate install with etch on a 1 GB USB-memory (or use a
previous one for which the boot image is saved). The 1-GB in the
upper USB-connector and the (soon to be encrypted) 2GB memory in
the lower port.
2) Fill a second (2GB) USB-memory with garbage from /dev/urandom,
create two partitions, one for / and one for swap, and then use
luksFormat on these, after which opening them and using mkfs.ext3
and mkswap is necessary.
3) Copy the complete fs from the first install to the encrypted / partition.
4) Boot from the intermediate media (with both USB-memories inserted),
use cryptsetup to open and mount the encrypted / partition.
5) Chroot into the encrypted partition and flash the boot info from
that (dpkg-reconfigure linux-image-$(uname -r)), after modifying
/etc/fstab and /etc/crypttab.
6) Reboot.
Here is how it worked out.
1) Is well described on the net, e.g. the one on cyrius.com. In
addition it is necessary to install cryptsetup, as this is
necessary to open the encrypted / and chroot into it later. Note
that installing cryptsetup triggers a rebuild of the initramfs and
boot image.
2) Can be done on the slug, but I actually did it on my desktop.
3) Can be done on the slug, but is actually easier on a separate
computer as copying a live / fs can be tricky. For example
/dev is filled with files from udev on a running system and looks
different otherwise.
4) Nothing special.
5) Here are some differences compared to the wiki howto. As I did not
install yaird there was no yaird configuration to modify. Further,
note that the modifications of fstab and crypttab needs to be done
prior to calling dpkg-reconfigure of the linux-image package, as
the encrypted media (in this procedure) is inserted into the slot
where it is planned to end up, and the intermediate media in the
other slot.
6) Some minor difficulties here. During the boot, everything worked
fine up to cryptsetup was run, which failed because sda had not yet
been detected. Well, the usb hub had been detected but not the
inserted media. A section of the boot log (captured from the serial
port) follows below. As you can see the boot process falls back to
busybox and a shell and it is possible to use cryptsetup in the
initram image to open the partitions, and after exiting the shell
the boot process continues normally. In the yaird configuration of
the wiki howto there is a "waitusb" section, which is essentially
the only one I used for my prior install as I had no key file and
did not need the hacks for that. It seems a similar configuration
would be needed for this solution as well, but I have not read the
manual page for mkinitramfs closely enough yet. Any tips are
appreciated.
snip
hub 3-0:1.0: 5 ports detected
usb 3-1: new high speed USB device using ehci_hcd and address 2
Done.
usb 3-1: configuration #1 chosen from 1 choice
Begin: Mounting root file system... ...
SCSI subsystem initialized
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
Begin: Running /scripts/local-top ...
Loading Intel IXP400 ethernet driver
FATAL: Module ixp400_eth not found.
Failed to load Intel IXP400 ethernet driver
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
Setting up cryptographic volume croot (based on /dev/sda1)
cryptsetup: Source device /dev/sda1 not found
Done.
Begin: Waiting for root file system... ...
Vendor: SanDisk Model: U3 Cruzer Micro Rev: 4.05
Type: Direct-Access ANSI SCSI revision: 02
Vendor: SanDisk Model: U3 Cruzer Micro Rev: 4.05
Type: CD-ROM ANSI SCSI revision: 02
SCSI device sda: 3999373 512-byte hdwr sectors (2048 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
SCSI device sda: 3999373 512-byte hdwr sectors (2048 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
sda: sda1 sda2
sd 0:0:0:0: Attached scsi removable disk sda
Done.
Check root= bootarg cat /proc/cmdline
or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/mapper/croot does not exist. Dropping to a shell!
BusyBox v1.1.3 (Debian 1:1.1.3-4) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
(initramfs) ./sbin/cryptsetup luksOpen /dev/sda1 croot
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
(initramfs) ./sbin/cryptsetup luksOpen /dev/sda2 cswap
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
(initramfs) exit
Boot continues normally. End of install-story.
As for performance on an encrypted / fs, the
compiling-heimdal-1.0-5-on-a-slug-with-sufficient-swap-enabled-competition
has a winner. The un-encrypted slug wins on 4 hours 41 minutes,
compared to the 4 hours 57 minutes for the slug running on encrypted /
and swap. Not a significant difference. Do note however that this was
not done on the same media. The un-encrypted install was on a Kingston
1GB memory (not the cheapest stuff about a year ago) and the encrypted
install on a 2GB Sandisk Cruzer. I don't know if there are any
significant performance differences on those. Running the slug on an
encrypted media feels about as (un)responsive as running it on
un-encrypted media.
Anders
PS I did actually have one problem. When I started out I placed a 2GB
memory with two already encrypted partitions, ext3 and swap, in the
lower port and a 1GB in the upper. I then initiated an install of etch
on the upper stick. That install failed at the stage where flashing
the boot memory should be done. The apparent issue was the flash
process being killed by kernel oom. It was strange because I had given
the 1GB stick a 370MB swap partition, but I do think the installer had
tried to use the un-unlocked swap partition on the 2GB memory. I had
previously done an install like that but then the lower memory stick
was formated with a single fat partition which was deleted at a later
stage, and the install on the intermediate media worked fine at that
time.
Reply to: