On Sat, 2010-06-26 at 18:17 +0200, Milan Broz wrote:
With recent kernel and flush (issuing barrier internally) device-mappera) What is recent? ;)
properly propagates barrier request.
b) The barrier thingy,... does it have to be supported by the thing
(e.g. filesystem, LV, etc.) on top? Or is this something generically
implemented for flushing?
But note that you are running shutdown scripts from device itselfUhm what exactly do you mean?
if it is root-fs script itself produces reads to the device.
But from the security point of view dm-crypt encryption key remains in memoryHow long is this about staying in the RAM (after poweroff)?
because you cannot properly remove LUKS device thus wipe the key.
Anyone with proper boot image can recover such key from RAM memory using
so called cold-boot attack.
And after reboot.... isn't everything set to 0x0? Otherwise,... booting
e.g. another OS or a compromised Linux could leak the key...
You have several options how to solve this, but I am afraid all requireI've already feared that... so we need de-initramfs? ;)
some kind of ramdisk, where are the basic tools are copied before unmounting
root-fs and unmapping devices and reboot.
(For non-root devices it is easy, you can even call luksSuspend to wipe
key on still active device as workaround before reboot.
I guess non-root devices should be cleanly closed, with luksClose, or
After luksSuspendIsn't it possible to patch the kernel,.. that always when halting or
device is frozen - until the key is provided back using luksResume.
So only some e.g. page cache leaks of plaintext data are possible -
but not encryption key itself.)
rebooting,.. it "simply" wipes _ALL_ dm-cryptkeys available,...
And why/how are plaintext leaks possible?
I mean something like this on shutdown:Already thought about that before,... but it seems impossible to me,...
- create ramdisk containing basic utilities
(mount, sync, lvm, cryptsetup, halt, etc)
- remount device read-only, iow sync and flush write IO
- switch to ramdisk, all command now must run from there
- try to cleanly unmout root-fs, deactivate underlying LV, deactivate LUKS
- if deactivation fails, fallback to wipe LUKS device key in memory
(more options here, like trying to dmsetup remove -f do remap to error target,
which disconnects underlying devices and allows deactivate them,
but it is quite dangerous)
(sounds like we need shutdownramfs but initramfs can be probably reused here:-)
to convice distros to do that...
And it's quite complex I guess,... given the fact that there are
basically arbitrary ways to stack your block devices...
Right now when I shutdown,... I get errors for lvm/dm-crypt/md,... as
they all can't close there devices,... as the root-fs is just ro-mounted
(ok the Debian cryptsetup package seems to not display that error,.. but
it's probably there).