--- Begin Message ---
concerning full loop-AES support for yaird (and for initramfs-tools),
I would like to discuss the idea of a common configuration file for
First of all, why could an extra config file be needed?
The problem with loop-AES devices is that most, but not all device
attributes required to set up a device with losetup can also be
retrieved by calling losetup (i.e. with 'losetup -a'). More specifically,
losetup output can not be used to gain information about the GPG key file
used for (possibly multi-key mode) encryption.
An existing solution is to describe a loop device with a loop= option
for the underlying device in fstab, along with gpgkey= and optionally
However, such an fstab entry is only feasible for loop devices which are
directly mounted (i.e. /dev/hda3 => /dev/loop0 => "/home"), but fails to
work for more complex setups in which loop devices are not mounted, like
using an encrypted loop-AES device as a physical LVM volume.
For yaird, I recently wrote full loopback and loop-AES device support.
As to handling GPG keys, there are two modes of operation, either
copying the GPG key (and optionally GPG home directory) to the initramfs
image, or mounting a device containing the key (and GPG home directory)
upon boot (comparable to the build-init.sh script accompanying
This code handles every corner case one could think of regarding loop-AES
devices, but there exists a (at least to me) major design flaw with the
code (which is also the reason why I was not yet confident to publish it
to the yaird list or BTS):
In order to solve the above dilemma with GPG keys, a new config option
(or more precisely a goal) had to be introduced, which specifies for
each GPG key encrypted loop-AES device
* the loop device (i.e. /dev/loop0),
* an absolute GPG key path (compare gpgkey= fstab option),
* optionally, a GPG home directory (compare gpghome= fstab option),
* and optionally, a mount point on the initramfs image, if the key device
is to be mounted upon boot (instead of copying the key to the image).
This works very well, but does shows its weaknesses when running yaird
in --test mode (where the config file is not read and thus yaird does
not have the required information about keys), and more importantly:
It is a *serious abuse* of the yaird config file. Device configuration
info should never be located in an initramfs creator config file, but
instead gained from a device-specific config file or tool (e.g. mdadm,
cryptsetup and /etc/crypttab, (pv|vg|lv)display, ...).
Finally, this is where my idea for a loop-AES config file comes in.
I propose to have a file (named something like '/etc/loopaestab' or
maybe '/etc/default/loopaes') with the loop-aes-utils package, that
fully describes every loop-AES device for which the configuration
cannot be derived from losetup output or fstab.
The format could be modeled after /etc/crypttab, for example:
# <target name> <source device> <options>
/dev/loop5 /dev/md0 encryption=AES256,gpgkey=/etc/keys/root.gpg
The following options would be supported:
- offset=..., sizelimit=..., encryption=..., loinit=...
These options can also be parsed from losetup output, and would
strictly have to match with the actual loop device configuration.
- pseed=..., phash=..., itercountk=...
These options should be available for completeness only.
An initramfs creator seeing these options would probably fail
with an "unsupported option" message: We do not ever want to encrypt
root filesystems with random keys, for example.
- gpgkey=..., gpghome=...
These are the options we are so desperately trying to retrieve.
This option would be the only loop-AES losetup unrelated option.
If the keyword "gpgmount" is specified, the initramfs creator is
instructed to mount the (unencrypted) device which contains the GPG
key [gpgkey=...] (and optionally GPG home directory [gpghome=...])
If the keyword "gpgmount" is not specified, the GPG key (and
optionally GPG home directory) would be directly copied to the
image by the initramfs creator.
This seems to be the most elegant solution, and the information about
loop-AES devices would be collected in a central place, and with a
package which it belongs to, namely loop-aes-utils.
It would also coexist peacefully with any potentially available
fstab entries: An initramfs creator would check for loop-AES info
* losetup output (partial description),
* /etc/fstab entries with a loop= option (full description) and
* /etc/loopaestab entries (full description),
and make sure that these match for each loop device.
Now, what do you think of this idea?
(I was not sure about where to send this first; it should maybe be
coordinated with at least the initramfs-tools and yaird maintainers.)
--- End Message ---