[pkg-cryptsetup-devel] Bug#587222: Bug#587222: cryptsetup does not/cannot close dm-crypt devices, if root-fs is on it, but does also not warn about it

[Jonas Meurer]

Hey Christoph,

On 26/06/2010 Christoph Anton Mitterer wrote:
> This is rather for the records, than a real bug.

To be honest, I don't like the idea of using the bug tracking system as
a discussion archive. As maintainer, I like to keep the count of open
bugs against packages low. It's generally better to document
controversial topics in the package or at documentation pages.

Maybe it's time to setup a cryptsetup wiki page at wiki.debian.org,
which documents all these discussion we have. I don't have the time to
maintain it, so feel free to setup, as long as mention all arguments,
and try to keep the documentation neutral ;-)

> I'm currently investigating in the problems that occur, when having fully
> encrypted systems (root-fs on dm-crypt) and the block layers are even stacked
> (e.g. with lvm2, mdadm, etc).
> 
> I noticed a problem in lvm2, that when the root-fs is on top of lvm, it cannot
> close the VG on shutdown/reboot, as / is only remounted-ro (which even happens
> after lvm2 stop)... anyway.

this is a real problem, and I'm glad that you started the discussion
at the linux kernel mailinglist. It would be great to fix the shutdown
process in debian in a way that all keys are wiped from memory.

> The same problem must obviously appear with cryptsetup.
> However, I never saw a warning.
>
> Do you generally not warn, if devices could not be closed, or just for root?
> If you generally do not warn that could be a problem, if e.g. users set up
> dm-crypt devices on a loopback device, because people wouldn not notice,
> if closing of dm-crypt device did not work, and therfore also not closing
> of the loopback device and clean unmounting of the underlaying filesystem.

both init scripts tell you that the to-be-stopped dm-crypt device is
still busy. Just run '/etc/init.d/cryptdisks stop' on your running
system to see what happens:

Stopping early crypto disks...cswap1 (busy)...ctemp1 (busy)...clvm1 (busy)...done.

This for sure holds as well for encrypted root devices. Both at
'cryptdisks stop' and at 'cryptdisks-early' stop, you see the message:

Stopping remaining crypto disks...hda2_crypt (busy)...done.

> For the root-fs it could be a problem, if it's not secured that on the
> remount,ro of the root-fs just before halt/reboot, everything that the
> fs worte out, has already passed dm-crypt (and further) layer to the disk.
> I'll ask at lkml on how this works.

I think that this already became clear in the discussion: remount,ro
should be enough to prevent data loss. But it's not enough security
wise, as the dm-crypt key still is in memory.

Next cryptsetup package upload should fix the boot/halt order of
cryptdisks(-early) initscripts for non-root encryption. But I don't know
a solution for encrypted root devices, and I've never heard about
haltramfs or something like that.

To secure the locking of non-root encryption even more, I'd like to run
luksSuspend for devices where luksClose fails.

Milan, if you're reading this: does luksSuspend work for plain dm-crypt
devices as well?

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20100627/7dfdb08f/attachment.pgp>