[Pkg-cryptsetup-devel] Questions about cryptsetup/initramfs

[David Härdeman]

On Tue, Jun 24, 2008 at 09:24:40PM +0200, Christoph Anton Mitterer wrote:
>On Tue, 2008-06-24 at 14:58 +0200, Jonas Meurer wrote:
>> exactly, in crypttab you use the UUID of the LUKS device.
>I'm not sure if I've already bug-reported this,.. but there is no LABEL
>for LUKS devices,... and thus only UUID works,... but there seems to be
>some code in cryptsetup,.. that thinks that LABEL would work, too.

Riddle me this....read the LUKS specification 
(http://luks.endorphin.org/LUKS-on-disk-format.pdf) and find where any 
label would be stored...

>The problems with this go even further:
>1) while grub-pc (grub2) detects that it mus set root=
>to /dev/mapper/sda2 it seems not to be able to use it's UUID (as it does
>per default with non-dm-crypt-devices).
>2) When I e.g. use LABEL= in fstab, but device-names (/dev/sda or so) in
>crypttab,.. cryptsetup was not able to detect root and didn't write
>this /conf/conf.d/cryptroot (in the initrd).
>Perhaps there might be other problems,... any idea here?

I have no idea what the question is...

>> > What about the kernel-root=-parameter,... is it LUKS's UUID or the plain
>> > decrypted-fs UUID/LABEL ?
>> > Or should one use something like /dev/ram0 or so?
>> I'm not sure about that one, but I guess that the kernel root parameter
>> is used by the initrd for mounting the root device _after_ the dm-crypt
>> mapping has been setup.
>I think so too,.. perhaps David is able to clear this.

Riddle me that...check the source of initramfs-tools:

(david at basil:~/tmp)$ apt-get source initramfs-tools
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Need to get 66.6kB of source archives.
Get:1 http://ftp.nl.debian.org unstable/main initramfs-tools 0.92b (dsc) [996B]
Get:2 http://ftp.nl.debian.org unstable/main initramfs-tools 0.92b (tar) [65.6kB]
Fetched 66.6kB in 0s (180kB/s)    
dpkg-source: extracting initramfs-tools in initramfs-tools-0.92b
dpkg-source: info: unpacking initramfs-tools_0.92b.tar.gz
(david at basil:~/tmp)$ cd initramfs-tools-0.92b/
(david at basil:~/tmp/initramfs-tools-0.92b)$ fgrep -r root= .
./scripts/local:                                echo "WARNING bootdevice may be renamed. Try root=/dev/sd${suffix}"
./scripts/local:                                echo "WARNING bootdevice may be renamed. Try root=/dev/hd${suffix}"
./scripts/local:                echo "  Check your root= boot argument (cat /proc/cmdline)"
./scripts/nfs:  # nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
./update-initramfs:             && groot=$(awk '/^root/{print substr($2, 2, 3); exit}' \
./debian/changelog:  * init: Check for root=/dev/nfs. Parse ip kernel command line for nfsroot.
./debian/changelog:    #357332 works for 3 digit roots, but not for hdc6 aka root=1606.
./debian/changelog:    root=LABEL=myrootfs or root=UUID=92addf34-0f02-4a0e-bfb2-cbaa1e907b77
./hook-functions:       eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"
./hook-functions:               root="/dev/disk/by-uuid/"$(/lib/udev/vol_id --uuid ${root}) 2>/dev/null
./hook-functions:       root="$(readlink -f ${root})"
./hook-functions:               root=${root#/dev/md/}
./hook-functions:               root=${root#/dev/}
./init: root=*)
./init:         ROOT=${x#root=}
./init: nfsroot=*)
./init:         NFSROOT="${x#nfsroot=}"
./initramfs-tools.8:Use root=/dev/nfs for NFS to kick to in.
(david at basil:~/tmp/initramfs-tools-0.92b)$ cat init
...
# Parse command line options
for x in $(cat /proc/cmdline); do
        case $x in
...
        root=*)
                ROOT=${x#root=}
                case $ROOT in
                LABEL=*)
                        ROOT="/dev/disk/by-label/${ROOT#LABEL=}"
                        ;;
                UUID=*)
                        ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
                        ;;
...
(david at basil:~/tmp/initramfs-tools-0.92b)$ fgrep -rl ROOT .
./scripts/local-top/lvm
./scripts/local
./scripts/nfs
./scripts/functions
./conf/initramfs.conf
./debian/changelog
./initramfs.conf.5
./hook-functions
./mkinitramfs.8
./init
./mkinitramfs
(david at basil:~/tmp/initramfs-tools-0.92b)$ cat scripts/local
...
        mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}
...

I think that should get anyone started...


>However,.. in the meantime I've read in the kernel docs
>(Documentation/inird.txt or so) that in the "new way" this should be set
>to /dev/ram0 ... so I assume Debian's initrd still use the "old way".
>Is this going to be changed, David?

I'll answer a question with a question....is an initrd the same as an 
initramfs environment? (Google will tell you)

>>> 1) The UUID/LABEL in /etc/fstab and what mount/fsck and so on look
>>> for,...
>>> Is this done by simply searching to all partitions that appear
>>> in /proc/partitions (where also dm-crypt partitions appear as dm-0,...)?
>> I guess that is searches for both in /dev/disk/by-{label|path}/
>You think? I didn't check it but I would have thought, that udev itself
>(which creates those /dev/disk-symlinks) would look at the kernel
>provided /proc/partitions, because this information can probably not
>resolved in user-space,.. or can it?

Read udev sources (the answer is...of course it can, label and uuid are 
stored on disk, userspace can read the disk...)

>> > What is that
>> > ID_FS_UUID_ENC and ID_FS_LABEL_ENC and ID_FS_LABEL_SAFE? In my case it's
>> > always the same as the base-property (ID_FS_UUID and ID_FS_LABEL).
>> It is indeed always the same. I don't know what the exact difference is
>> and in which situations there is a different value. But i've never seen
>> such a situation anyway.
>David,... do you have any idea perhaps?

It ain't rocket science...I had no idea what the answer was to your 
question but it took me 15 seconds to find out...

(david at basil:~/tmp)$ apt-get source udev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Skipping already downloaded file 'udev_0.114-2.dsc'
Skipping already downloaded file 'udev_0.114.orig.tar.gz'
Skipping already downloaded file 'udev_0.114-2.diff.gz'
Need to get 0B of source archives.
dpkg-source: extracting udev in udev-0.114
dpkg-source: info: unpacking udev_0.114.orig.tar.gz
dpkg-source: info: applying udev_0.114-2.diff.gz
(david at basil:~/tmp)$ cd udev-0.114/
(david at basil:~/tmp/udev-0.114)$ fgrep SAFE *
ChangeLog:      vol_id: add ID_FS_UUID_SAFE
ChangeLog:      rules: use ID_FS_UUID_SAFE
ChangeLog:  vol_id: ID_LABEL_SAFE will no longer contain fancy characters
RELEASE-NOTES:exports ID_FS_UUID_SAFE, just like ID_FS_LABEL_SAFE. For things like
RELEASE-NOTES:the creation of symlinks, the *_SAFE values ensure, that no control
(david at basil:~/tmp/udev-0.114)$ less RELEASE-NOTES

Answer:
In the future, we may see uuid's which are just simple character
strings (see the DDF Raid Specification). For that reason vol_id now
exports ID_FS_UUID_SAFE, just like ID_FS_LABEL_SAFE. For things like
the creation of symlinks, the *_SAFE values ensure, that no control
or whitespace characters are used in the filename.

>> > I mean in my setup the resumed system whould have to get the key again
>> > from the USB-stick,... e.g. wait for the correct one to be inserted,
>> > mount it and so on,.. does cryptsetup's script support this?
>> i guess that's not how suspend/resume works. if you suspend a system,
>> the ram/swap is saved, and if you resume, it is reloaded. and the ram
>> contains keys of all active encrypted disk.
>I meant suspend to disk and not to ram,... (the later is pretty unsecure
>one can get the unencrypted key from the RAM)
>
>AFAIK if you suspend to disk this is stored to the swap partition, which
>should be encrypted, right?
>Thus one would need a valid key (for swap, not necessary for root) in
>order to resume-from-disk.

Yes. Which is why the cryptsetup initramfs script and hook includes swap 
information whenever possible in the initramfs.

-- 
David Härdeman