On Sat, Apr 24, 2010 at 20:19, Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Sat, Apr 24, 2010 at 06:41:30PM -0400, Ryan Lynch wrote: >> 2) Is the LUKS/dm-crypt "mounting" (?) attachment process >> read-only and immune to concurrency problems? (Sorry, I'm not sure of >> the right terminology, here--"mount" is wrong, there's no FS involved, >> but what is the process of setting up the virtual block device >> called?) > > I would propose to call the process "mapping". > > AFAIK dm-crypt mapping is completely no-disk-access, i.e. not even > read as there is no metadata on disk. Well, to be exact, the > partition table gets read if you map a partition. I am not sure > about LUKS. > >> Based on what I've read, so far, I believe there's no problem WRT >> question #1. But I really don't know about question #2. > > LUKS could be a problem with regard to #2. I agree on #1. I found the LUKS specification (http://code.google.com/p/cryptsetup/wiki/Specification), and it doesn't seem like there are any write operations to the LUKS header during a normal mapping. Initialization and key management, yes, so I might have to be careful if I want to add/change/revoke a passphrase, but I haven't finished digesting that part, yet. Also, the man page for 'cryptsetup' mentions an interesting option: --non-exclusive This option is ignored. Non-exclusive access to the same block device can cause data corruption thus this mode is no longer supported by cryptsetup. There are references to it in the release notes for 1.07 and 1.10, the latter also mentioning that the option is currently disabled. There's a ticket mentioning it that seems to explain a little more (http://code.google.com/p/cryptsetup/issues/detail?id=34&can=1). I'm still trying to understand it, right now. I also had an idea to test the basic concept re: LUKS, with a much simpler local configuration: - Allocate a file big enough to hold a LUKS/dm-crypt volume (a few 10s of MBs should be enough). - Set up a first loopback device on the new file. - Set up a second loopback device, backed by either the file or the first loopback device. - Initialize an encrypted volume via the first loop device. - Checksum the "raw" LUKS header via the first loop device (e.g., `dd ... | md5sum`, can't remember the exact header size). - Map the encrypted volume via the first loop device.. - Checksum the "raw" LUKS header, again, via the first loop device, and compare it to the original. If it's changed, we have a problem. - Map the encrypted volume on the second loop device.But - Checksum the "raw" LUKS header, via both loop devices, and compare w/ previous. If it's changed, we have a problem. - Repeat w/ un-mapping operations, too. I'm a little worried that this might be the exact situation that the '--non-exclusive' option was supposed to handle. If it doesn't work, I'm probably just going to set up an iSCSI target and attach from two different machines. Less convenient, but if this works, I'll have to do it, anyway. (BTW: If gmazyland happens to read this, and he doesn't mind explaining this for me, I would really appreciate the help.) > One data-loss risk I see is that dm-crypt does not "sync" until > unmapped (found that out when zeroing a new dm-crypt partition, > the start of the partition only got overwritten after unmapping). > So for a hard sync where you need to be sure the data is on disk, > you would need to remove the mapping. But this is already > problematic with modern disks in a power-loss scenario. You do > not really get a write-through these days. But if you force > disk flushes by umounting (the only reliable way these days, it > seems), remember to unmap dm-crypt as well. I don't think I understand this part very well: Is dm-crypt operating synchronously WRT the underlying device? If it's really async, then I don't think any of this is going to work, unless it's possible to disable the block layer cache. Each host's lock manager daemon notifies the other hosts when it performs any kind of write operation, so that if the other hosts can drop any affected bits from their FS caches. But the lock managers aren't aware of the block layer cache (if any), so wouldn't that create the potential for concurrency problems? I just glanced over the DM I/O docs, in the kernel source. Looks like sync and async are both supported. Just when I thought I had this thing figured out... -Ryan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
