sync will hang on luksSuspend'ed device

[GoogleCodeExporter]

In the context of a regular luks-encrypted file which is loop-mounted.

If it is suspended :

1) You may later sync what will apply to all devices included suspended ones.
As a consequence sync will hang.

2) you may want to clear the filesystem cache in order to avoid this problem:
$ ll dir/rep1
blah
$ cryptsetup luksSuspend dir
$ ll dir/rep1
blah
$ ll dir/rep2
# no cache, so here it hangs until luksResume

In order to avoid cold-boot attacks, you may want to 
echo 1 >> /proc/sys/vm/drop_caches # or echo 3

But this won't work after luksSuspend (not sure if this is because no sync 
happened first)

One's workaround could be to issue a sync + drop_caches *first* and only then 
luksSuspend.
But this pattern wouldn't apply very well in the case an application constantly 
uses the filesystem thus recaching information between the sync/drop_cache and 
the effective luksSuspend.

A way to solve that would be to allow sync/drop_caches to :
1) apply on a per-filesystem basics (see drop_pagecache_sb in 
kernel/fs/drop_caches.c)
2) allow drop_cache on a luksSuspend'ed filesystem (if this is possible)

While not exactly cryptsetup-responsibility, maybe something could be done 
about that.

Original issue reported on code.google.com by raphael....@gmail.com on 10 Mar 2014 at 1:14

[GoogleCodeExporter]

How it works:

- luksSuspend is basically device-mapper block device suspend (intended to 
allow online remapping of device) with additional wipe key from memory in 
dmcrypt. So by the definition:
 - no read/write operation can happen through suspended dmcrypt device - there is no valid key, we cannot encrypt/decrypt data. So sync after suspend is impossible.
 - waiting on IO for resume is just device-mapper functionality, all IO operation basically stall here.

(BTW I think sync is done by default inside suspend operation but not sure now.)

So yes, drop cache + sync should be run before luksSuspend (in theory).

I think drop_caches just issues some IO operation (flush dirty buffers), so it 
is unfortunately (in general) not possible to finish this for suspended dmcrypt 
device.

Anyway, this is not cryptsetup issue but kernel device-mapper subsystem one - 
so it should be discussed on dm-devel (dm-devel@redhat.com) list.

I'll make some note to ask later but cryptsetup cannot do anything here, it is 
really kernel issue.

Original comment by gmazyl...@gmail.com on 10 Mar 2014 at 7:58

• Changed state: Invalid