Multi-disk systems will likely have multiple LUKS devices open, so it is
important to also wipe the key for those devices.
However, entering a password to resume every device on wakeup is
tedious, so this patch attempts to resume all LUKS devices that have
a corresponding keyfile in /etc/crypttab once the user successfully
unlocks the device containing the root filesystem.
The parsing of /etc/crypttab is rudimentary and no special cryptsetup
options are handled, but this covers the conventional approach of
"unlock the root device, then unlock the other disks on the system with
keyfiles stored on the root device, specified in /etc/crypttab".
Note: Only 4abc1d094ee0dd950285125ae5d4c484ce6d69a0 is strictly
concerned with handling multiple LUKS devices. The other commits are
concerned with code organization and security (poweroff on failure).
I hope some of this looks appealing to you!
EDIT: I am happy to break this up into smaller pull requests if you
like. Thanks!
Patch 4abc1d094ee0dd950285125ae5d4c484ce6d69a0:
Multi-disk systems will likely have multiple LUKS devices open, so it is important to also wipe the key for those devices.
However, entering a password to resume every device on wakeup is tedious, so this patch attempts to resume all LUKS devices that have a corresponding keyfile in /etc/crypttab once the user successfully unlocks the device containing the root filesystem.
The parsing of /etc/crypttab is rudimentary and no special cryptsetup options are handled, but this covers the conventional approach of "unlock the root device, then unlock the other disks on the system with keyfiles stored on the root device, specified in /etc/crypttab".
Note: Only 4abc1d094ee0dd950285125ae5d4c484ce6d69a0 is strictly concerned with handling multiple LUKS devices. The other commits are concerned with code organization and security (poweroff on failure).
I hope some of this looks appealing to you!
EDIT: I am happy to break this up into smaller pull requests if you like. Thanks!