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
signature.asc
Description: Digital signature
