Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#31877 - [cryptsetup] keyfile in encrypted initramfs hook support

Attached to Project: Arch Linux
Opened by Zack Buhman (buhman) - Wednesday, 10 October 2012, 11:37 GMT
Last edited by Christian Hesse (eworm) - Saturday, 04 November 2017, 23:06 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No



It is possible, though not very well documented, in grub 2.00 (photo of what I'm talking about attached) to have the /boot filesystem inside a LUKS container, and grub is capable of decrypting the master key, and unlocking the container to load the grub configuration, kernel, initramfs and so on.

This then makes for, in my opinion, a very sane opportunity to use the initramfs as a keyfile storage location, which solves the problem of not having to type the same passphrase twice on boot (currently there appears to be no magic that allows grub to pass the master key to the kernel), without having to resort to silliness like putting the keyfile on some unencrypted removable storage.

The greatest benefit, however, is that using this method, it is possible to then, in a way that doesn't potentially jeopardize the secrecy of the keyfile, kexec a machine without requiring human intervention in early-boot.


It seems that the current encrypt hook seems to make the assumption that all keyfiles can only be located on some sort of block device, rather than on the initramfs. So I made a quick hack (the primary goal being to modify the current hook as little as possible) that allows one to specify the location of the keyfile on initramfs.

The current patch is sub-optimal/ugly, however, because the kernel line ends up looking like "cryptkey=dontcare:/path/to/key:dontcare" or even "cryptkey=dontcare:/path/to/key". I am eagerly interested to hear your opinions on how to possibly improve the cryptkey parameters.
This task depends upon

Closed by  Christian Hesse (eworm)
Saturday, 04 November 2017, 23:06 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Should work with current code.
Comment by Zack Buhman (buhman) - Wednesday, 10 October 2012, 11:39 GMT
If it was not made clear initially, the way this would be set up is there would be at least two slots used to decrypt the master key, the first a passphrase typed on [re]boot, and the second the key used for mounting the root filesystem in early-boot. The key-storage-in-initramfs neither increases nor decreases overall "security".
Comment by Thomas Zelch (eltom) - Sunday, 01 March 2015, 05:28 GMT
I can confirm that this patch is working.
It would be great if it could be implemented.
Comment by David Manouchehri (Manouchehri) - Friday, 11 September 2015, 17:14 GMT
Based on Pavel Kogan's blog, this no longer seems to be necessary as mkinitcpio's encrypt hook now accepts a keyfile properly.