[dm-crypt] an official way to know if the underlying device is gone for all supported volume formats

.. ink .. mhogomchungu at gmail.com
Tue Mar 19 03:24:02 CET 2013


On Mon, Mar 18, 2013 at 6:01 PM, Milan Broz <gmazyland at gmail.com> wrote:

>
> On 18.3.2013 7:30, .. ink .. wrote:
>
>>
>> http://code.google.com/p/**cryptsetup/source/detail?r=**
>> f64064fe71363a14ab0c62359e451f**9cdc39dc50<http://code.google.com/p/cryptsetup/source/detail?r=f64064fe71363a14ab0c62359e451f9cdc39dc50>
>>
>>  The above commit log speaks of LUKS volumes,what about plain and
>> cryptsetup volumes? The return code for LUKS is vague too since the
>> log is not clear.
>>
>
> plain device doesn't have this problem, it initializes completely from
> mapping table (no real problem if underlying device disappeared).
>
> and what about truecrypt volume?
The point is that when the underlying device is gone,the API becomes
contradicting and unpredictable as it start to exhibit undocumented
behaviors.

if "crypt_init_by name" return non zero when the underlying device is gone
with LUKS volumes,it should return the same non zero value when the
underlying device is gone for both PLAIN and TRUECRYPT volume.

with PLAIN volume,"crypt_init_by_name" return 0 signifying success,but
"crypt_get_device_name" returns NULL,an undocumented return value so there
is a real problem with underlying device disappearing with PLAIN volumes as
the return value if unchecked segfault the program.

There is another API i do not remember at the moment than return
undocumented NULL in this situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20130318/a7412c7b/attachment.html>


More information about the dm-crypt mailing list