Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#24819 - [mkinitcpio] encrypted root fails to deactivate at shutdown
Attached to Project:
Arch Linux
Opened by voltaic (voltaic) - Wednesday, 22 June 2011, 03:12 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 04 April 2012, 00:32 GMT
Opened by voltaic (voltaic) - Wednesday, 22 June 2011, 03:12 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 04 April 2012, 00:32 GMT
|
DetailsDescription:
Encrypted root filesystem (LVM on top of LUKS) fails to deactivate during shutdown. Encrypted swap, on the other hand, is correctly deactivated. Additional info: * 2010.05 net install iso, x86_64 * mkinitcpio 0.6.15-1 * initscripts 2011.06.4-1 * grub2-bios 1:1.99-3 * all packages updated as of 6/21/2011 * mkinitcpio hooks used: base udev autodetect pata scsi sata usbinput encrypt lvm2 filesystems * / is an LVM logical volume, which resides on a LUKS volume Steps to reproduce: 1) Issue shutdown command on a system with a root parition which is an LVM volume atop a LUKS volume. 2) Observe status messages 3) "Deactivating encrypted volumes: root..failed swap..ok I originally commented on issue 23889 thinking that this was an rc.shutdown issue. Tom Gundersen suggested that the problem I am describing here is related to mkinitcpio. If someone can help me trace the source of the error I will be happy to provide debug output, etc. I am trying to understand if there are negative consequences to what I've observed. Upon reboot I do not see any problems when the partitions are remounted. 
shutdown_bug.png
(3.7 KiB)
|
This task depends upon
Closed by Dave Reisner (falconindy)
Wednesday, 04 April 2012, 00:32 GMT
Reason for closing: Implemented
Additional comments about closing: mkinitcpio 0.8.6
Wednesday, 04 April 2012, 00:32 GMT
Reason for closing: Implemented
Additional comments about closing: mkinitcpio 0.8.6
However, closing LVM or encryption requires umounting the file system on it - which in this case is the root file system. You can imagine that this is rather hard to do.
I started a proof-of-concept implementation of a "deinitramfs" with the capability of umounting root [1]. It does not handle LVM or encryption yet, but it is a start.
As for the negative consequences: Not closing LVM is harmless. But failing to close a dm-crypt mapping will not wipe the encryption key from memory and will make you potentially vulnerable to cold boot attacks, allowing an attacker to gain access to your key (force a reboot, boot with a prepared image that scans your memory for cryto-specific structures, extract the key).
[1] http://projects.archlinux.org/users/thomas/deinitramfs.git
At the expense of repeating what you just said, am I correct in saying that we currently cannot close an encrypted root filesystem at shutdown/reboot? If so, I'll have to rethink the benefits of using encryption with root.
http://code.falconindy.com/cgit/mkinitcpio.git/log/?h=shutdown-disassemble
Testers welcome (and wanted). If you want to report that it doesn't work, I need the output of 'lsblk' (from util-linux) to be able to troubleshoot.