Re: encrypted root fs on a slug and crypto-modules
On Sun, 2008-03-09, at 21:24:50 +0100, Martin Michlmayr wrote:
> * Anders Lennartsson <anders.lennartsson@foi.se> [2008-02-24 07:42]:
> > Feb 23 19:03:55 anna[9635]: DEBUG: resolver (crypto-modules): package doesn't exist (ignored)
> >
> > and a short investigation gives that it seems natural because they are
> > not built by the source package:
> > http://packages.debian.org/source/etch/linux-kernel-di-arm-2.6
>
> Thanks for your report. I'll add crypto-modules when we update the
> installer to 2.6.24. (Which will happen after beta1 is released,
> which should hopefully be soon.)
> --
> Martin Michlmayr
> http://www.cyrius.com/
Thanks for spotting my report and adding the modules.
As a further note on the subject of this thread, I did manage to
install Debian Etch on a fully encrypted USB-stick (1 GB) with two
partitions, one for root and one for swap. I used default settings for
LUKS encryption which I belive is 128 bits. My impression is that it
didn't really affect performance but I have not made any objective
tests of this.
Building the heimdal 1.0.1 packages (yes a backport) on a slug
with un-encrypted 700 MB root partition and 300 MB swap (1GB SanDisk
USB-stick) takes between 4 and 5 hours. My plan was to check how long
time this took on the same device but with encrypted
partitions. Unfortunately I selected a slightly smaller swap partition
(250 MB or so) and gcc or the linker failed at some point when memory was
depleted. The evidence of this was seen in the syslog.
My install procedure was similar to the wiki entry
http://www.nslu2-linux.org/wiki/Debian/CreateAnEncryptedRootFilesystemWithLUKS
and I wouldn't have made such rapid progress without this
information. Thanks guys!
A big difference is that instead of a key hidden in a file, I opted
for entering the LUKS pass phrase at boot time but over a serial
port. Some soldering was necessary to make this possible but that is
described in several good web articles and my serial port works
nicely.
The following is a crude outline of how I managed to do the install. I
may have omitted something crucial, which you may find out if you try
to copy the procedure.
Since currently the install process can not be done directly onto an
encrypted fs, I used two 1-GB USB memory-sticks. One was for a normal
install and the other for the encrypted install. For the first install
I placed a stick in the upper USB connector. This will be
/dev/sdb. After a normal install of Debian on this USB-memory, I
installed the package cryptsetup. Then I inserted the second media in
the lower connector. This is /dev/sda. Prior to that I had tested the
second USB-memory on my desktop and also filled it with stuff from
/dev/urandom on that computer, which is slightly quicker than the
slug. But I did also test this on the slug, and 1 GB was filled with
garbage in about half an hour. Not so bad.
After partitioning similarly sized partitions (but not exactly :( , I
created encrypted partitions and opened them, built ext3 (/dev/sda1)
and swap (/dev/sda2) respectively on them, and mounted sda1. Then I
copied the installation from the unencrypted install, and then came
the tricky part, configuring and writing the boot stuff. A chroot to
/dev/sda1 (or where it is mounted...), installing yaird, and some
fiddling with files according to the wiki entry above, resulted in a
successful boot into the encrypted root partition after just one(!)
reflash with the boot image for the unencrypted stick. This points to
the accuracy of the wiki howto. (Do please follow their advice to make a
copy of the boot sectors after the first install.) Since I was
planning to keep the stick with the encrypted fs in the lower port it
was actually all quite simple. I had to configure the system (yaird,
fstab, ...) to have /dev/sda1 for root, and as this partition was
actually already located there left litte room for confusion (in the
second try). In addition, yaird needs only to know about the standard
procedure for obtaining a LUKS pass phrase at boot time, which the
serial port console solves. So no hacking for using a key-file was
necessary.
With minicom configured to the correct tty (and functionaly checked
before rebooting), the prompts for pass phrases came as expected
during the boot process, after which the boot continued normally.
Anders
Reply to: