[dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Emily Williams]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Today I made a rather large mistake, running fsck.ext4 on the raw volume
(/dev/sdk1) instead of the mapped volume
(/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible to
recover from this once it is done and the cryptosetup lukeOpen passphrase
no longer works.

I'd like to avoid this ever happening in the future. Is there any way to
put in safeguards to minimize the chance of this ever happening again?

I've found very few references to this problem after a lot of searching -
below is one I did find that at least made me think I wasn't going crazy -
so I'm guessing I'm just doing something silly that makes fsck.ext4 think
that the raw volume is actually something it should take a whack at fixing,
instead of saying something sensible like "that doesn't look like an ext4
filesystem, go away", which as far as I can see should be the case - it's
encrypted, so it shouldn't "look like" anything except crypto_luks metadata
and random data in no discernible format. And yet fsck.ext4 seems to be
behaving as though it sees an ext4 filesystem with errors.

From: poptones
Subject: (not LUKS) why did fsck on an encrypted source work?
Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes ago)

Accidentally (yes, I was still a little rattled from the earlier mistake) I
ran this on /dev/md0 instead of /dev/mapper/md0. After a couple of hours it
began the final pass and I saw it report moving files - about 20,000 object
moved to /lost&found.

Somewhat perplexed and confused, and learning not to play with new toys
when overtired,
-Emily

[-- Attachment #2: Type: text/html, Size: 1820 bytes --]

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[ken]

Emily,

This seems it would be an easy mistake to make, especially if one's 
working on an unfamiliar system or multiple heterogeneous systems or 
after a long time during which dm-crypt has been working, as it should, 
transparently and its presence is forgotten.  I could see myself making 
the same mistake.  So thanks for bringing up the issue.

This will likely be the least knowledgeable reply you'll get, so please 
defer to any other replies.

I would think that the most assured method to prevent this mistake would 
need to be from the side of fsck itself.  So I would rename fsck to 
something else, say fsck.bin.  Then a shell script would call fsck.bin 
after first checking the device specified.  One check I can think of 
would consist of an attempt to mount the specified device to a temporary 
mountpoint.  Only if the mount succeeds, after the device is unmounted, 
would fsck.bin be called.  Of course each of the various 
fsck.{filesystem} executables should get this sort of wrapping.

True, this is a bit of a cludge.  And there's probably two or three more 
elegant cludges possible.  And a true fix would need to be incorporated 
into all the fsck.{filesystem} executables themselves.  But that would 
probably take awhile to happen and then flow out to all the distros. 
Something like the above might serve the purpose until all that happens.



On 12/27/2012 01:12 AM Emily Williams wrote:
> Today I made a rather large mistake, running fsck.ext4 on the raw volume
> (/dev/sdk1) instead of the mapped volume
> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible
> to recover from this once it is done and the cryptosetup lukeOpen
> passphrase no longer works.
>
> I'd like to avoid this ever happening in the future. Is there any way to
> put in safeguards to minimize the chance of this ever happening again?
>
> I've found very few references to this problem after a lot of searching
> - below is one I did find that at least made me think I wasn't going
> crazy - so I'm guessing I'm just doing something silly that makes
> fsck.ext4 think that the raw volume is actually something it should take
> a whack at fixing, instead of saying something sensible like "that
> doesn't look like an ext4 filesystem, go away", which as far as I can
> see should be the case - it's encrypted, so it shouldn't "look like"
> anything except crypto_luks metadata and random data in no discernible
> format. And yet fsck.ext4 seems to be behaving as though it sees an ext4
> filesystem with errors.
>
> From: poptones
> Subject: (not LUKS) why did fsck on an encrypted source work?
> Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes ago)
>
> Accidentally (yes, I was still a little rattled from the
> earlier mistake) I ran this on /dev/md0 instead of /dev/mapper/md0.
> After a couple of hours it began the final pass and I saw it report
> moving files - about 20,000 object moved to /lost&found.
>
> Somewhat perplexed and confused, and learning not to play with new toys
> when overtired,
> -Emily
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

Hi Emily,

this is rather unfortnate. But I think something else went wrong
here. When I run e2fsck on a luks loop-file, it correctly 
recognizes there is no ext2/3/4 system in there:

------
root@gate:~/f/luks# e2fsck /dev/loop0
e2fsck 1.41.12 (17-May-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

root@gate:~/f/luks# 
-------

I think your partition could have contained old ext4 superblocks that 
were not erased. Or ext2fsck was run with some kind of --force option.
In both cases, what you saw is user error.

In particular, any partition should be compeltely erased before
a new filesystem or LUKS container is put on it, specifically
to avoid an unfortunate event like you had. Typically, recognizing
what is in a partitition is reliable. But if two different 
things get mixed (LUKS + ext4), a repair tool, that must be 
less careful about requiring correct signatures, could get confused.

Arno





On Thu, Dec 27, 2012 at 01:12:09AM -0500, Emily Williams wrote:
> Today I made a rather large mistake, running fsck.ext4 on the raw volume
> (/dev/sdk1) instead of the mapped volume
> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible to
> recover from this once it is done and the cryptosetup lukeOpen passphrase
> no longer works.
> 
> I'd like to avoid this ever happening in the future. Is there any way to
> put in safeguards to minimize the chance of this ever happening again?
> 
> I've found very few references to this problem after a lot of searching -
> below is one I did find that at least made me think I wasn't going crazy -
> so I'm guessing I'm just doing something silly that makes fsck.ext4 think
> that the raw volume is actually something it should take a whack at fixing,
> instead of saying something sensible like "that doesn't look like an ext4
> filesystem, go away", which as far as I can see should be the case - it's
> encrypted, so it shouldn't "look like" anything except crypto_luks metadata
> and random data in no discernible format. And yet fsck.ext4 seems to be
> behaving as though it sees an ext4 filesystem with errors.
> 
> From: poptones
> Subject: (not LUKS) why did fsck on an encrypted source work?
> Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes ago)
> 
> Accidentally (yes, I was still a little rattled from the earlier mistake) I
> ran this on /dev/md0 instead of /dev/mapper/md0. After a couple of hours it
> began the final pass and I saw it report moving files - about 20,000 object
> moved to /lost&found.
> 
> Somewhat perplexed and confused, and learning not to play with new toys
> when overtired,
> -Emily

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Richard]

On Thu, Dec 27, 2012 at 01:12:09AM -0500, Emily Williams wrote:
> Today I made a rather large mistake, running fsck.ext4 on the raw volume
> (/dev/sdk1) instead of the mapped volume
> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible to
> recover from this once it is done and the cryptosetup lukeOpen passphrase
> no longer works.

something strange going on fsck.ext4 will never do a destructive action 
without asking.

Don't reboot, don't panic perhaps something can be saved.

No idea what really happened though.


Richard

---
Name and OpenPGP keys available from pgp key servers

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Sven Eschenberg]

I think these are the 2 most common sources, when something like this
happens.

It would be interesting to know though:

Did the device ever hold an ext filesystem?
What was done before creating the luks container?

My best guess is, that the 'raw' device still had an intact secondary
superblock, which was found and used.

Are logs/console messages from the fsck run available, that could shed
some light on this?

I wonder how fsck checks for a superblock. I still assume, that chances of
having encrypted data in the right block on disk looking like a correct
ext-superblock is next to zero.

Regards

-Sven

BTW: Since Arno mentioned the confusion problem and I saw a md (devmapper)
name in the initial post, avoid md metadata v1.0 format if possible. Even
though it is clear to us humans, that a readable md metadata can not
possibly be inside the luks container, it's your best chance of ending up
with another desaster. Arno, could this be something for the FAQ?


On Thu, December 27, 2012 10:52, Arno Wagner wrote:
> Hi Emily,
>
>
> I think your partition could have contained old ext4 superblocks that
> were not erased. Or ext2fsck was run with some kind of --force option.
> In both cases, what you saw is user error.
>
> In particular, any partition should be compeltely erased before
> a new filesystem or LUKS container is put on it, specifically
> to avoid an unfortunate event like you had. Typically, recognizing
> what is in a partitition is reliable. But if two different
> things get mixed (LUKS + ext4), a repair tool, that must be
> less careful about requiring correct signatures, could get confused.
>
> Arno
>
>
>
>
>
> On Thu, Dec 27, 2012 at 01:12:09AM -0500, Emily Williams wrote:
>> Today I made a rather large mistake, running fsck.ext4 on the raw volume
>> (/dev/sdk1) instead of the mapped volume
>> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible
>> to
>> recover from this once it is done and the cryptosetup lukeOpen
>> passphrase
>> no longer works.
>>
>> I'd like to avoid this ever happening in the future. Is there any way to
>> put in safeguards to minimize the chance of this ever happening again?
>>
>> I've found very few references to this problem after a lot of searching
>> -
>> below is one I did find that at least made me think I wasn't going crazy
>> -
>> so I'm guessing I'm just doing something silly that makes fsck.ext4
>> think
>> that the raw volume is actually something it should take a whack at
>> fixing,
>> instead of saying something sensible like "that doesn't look like an
>> ext4
>> filesystem, go away", which as far as I can see should be the case -
>> it's
>> encrypted, so it shouldn't "look like" anything except crypto_luks
>> metadata
>> and random data in no discernible format. And yet fsck.ext4 seems to be
>> behaving as though it sees an ext4 filesystem with errors.
>>
>> From: poptones
>> Subject: (not LUKS) why did fsck on an encrypted source work?
>> Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes
>> ago)
>>
>> Accidentally (yes, I was still a little rattled from the earlier
>> mistake) I
>> ran this on /dev/md0 instead of /dev/mapper/md0. After a couple of hours
>> it
>> began the final pass and I saw it report moving files - about 20,000
>> object
>> moved to /lost&found.
>>
>> Somewhat perplexed and confused, and learning not to play with new toys
>> when overtired,
>> -Emily
>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> 9718
> ----
> One of the painful things about our time is that those who feel certainty
> are stupid, and those with any imagination and understanding are filled
> with doubt and indecision. -- Bertrand Russell
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

On Fri, Dec 28, 2012 at 03:46:45PM +0100, Sven Eschenberg wrote:
> I think these are the 2 most common sources, when something like this
> happens.
> 
> It would be interesting to know though:
> 
> Did the device ever hold an ext filesystem?
> What was done before creating the luks container?
> 
> My best guess is, that the 'raw' device still had an intact secondary
> superblock, which was found and used.

My thoughts also.

> Are logs/console messages from the fsck run available, that could shed
> some light on this?
> 
> I wonder how fsck checks for a superblock. I still assume, that chances of
> having encrypted data in the right block on disk looking like a correct
> ext-superblock is next to zero.

The ext2 superblock magic number seems to be 0xEF53. That is a bit 
short but still only gives something like 1 in 65536 probability of 
misdetection in encrypted data. I think we can rule that out 
for the moment. 

> Regards
> 
> -Sven
> 
> BTW: Since Arno mentioned the confusion problem and I saw a md (devmapper)
> name in the initial post, avoid md metadata v1.0 format if possible. Even
> though it is clear to us humans, that a readable md metadata can not
> possibly be inside the luks container, it's your best chance of ending up
> with another desaster. Arno, could this be something for the FAQ?

I am thinking about a "basic LUKS setup" section for the FAQ 
that is more in the nature of a mini-howto. Things like blanking
a previously used partition before a LUKS install seem to be 
not obvious to many people. Step-by-step instructions may help.

Arno
 
> 
> On Thu, December 27, 2012 10:52, Arno Wagner wrote:
> > Hi Emily,
> >
> >
> > I think your partition could have contained old ext4 superblocks that
> > were not erased. Or ext2fsck was run with some kind of --force option.
> > In both cases, what you saw is user error.
> >
> > In particular, any partition should be compeltely erased before
> > a new filesystem or LUKS container is put on it, specifically
> > to avoid an unfortunate event like you had. Typically, recognizing
> > what is in a partitition is reliable. But if two different
> > things get mixed (LUKS + ext4), a repair tool, that must be
> > less careful about requiring correct signatures, could get confused.
> >
> > Arno
> >
> >
> >
> >
> >
> > On Thu, Dec 27, 2012 at 01:12:09AM -0500, Emily Williams wrote:
> >> Today I made a rather large mistake, running fsck.ext4 on the raw volume
> >> (/dev/sdk1) instead of the mapped volume
> >> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible
> >> to
> >> recover from this once it is done and the cryptosetup lukeOpen
> >> passphrase
> >> no longer works.
> >>
> >> I'd like to avoid this ever happening in the future. Is there any way to
> >> put in safeguards to minimize the chance of this ever happening again?
> >>
> >> I've found very few references to this problem after a lot of searching
> >> -
> >> below is one I did find that at least made me think I wasn't going crazy
> >> -
> >> so I'm guessing I'm just doing something silly that makes fsck.ext4
> >> think
> >> that the raw volume is actually something it should take a whack at
> >> fixing,
> >> instead of saying something sensible like "that doesn't look like an
> >> ext4
> >> filesystem, go away", which as far as I can see should be the case -
> >> it's
> >> encrypted, so it shouldn't "look like" anything except crypto_luks
> >> metadata
> >> and random data in no discernible format. And yet fsck.ext4 seems to be
> >> behaving as though it sees an ext4 filesystem with errors.
> >>
> >> From: poptones
> >> Subject: (not LUKS) why did fsck on an encrypted source work?
> >> Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes
> >> ago)
> >>
> >> Accidentally (yes, I was still a little rattled from the earlier
> >> mistake) I
> >> ran this on /dev/md0 instead of /dev/mapper/md0. After a couple of hours
> >> it
> >> began the final pass and I saw it report moving files - about 20,000
> >> object
> >> moved to /lost&found.
> >>
> >> Somewhat perplexed and confused, and learning not to play with new toys
> >> when overtired,
> >> -Emily
> >
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> > --
> > Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> > GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> > 9718
> > ----
> > One of the painful things about our time is that those who feel certainty
> > are stupid, and those with any imagination and understanding are filled
> > with doubt and indecision. -- Bertrand Russell
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Milan Broz]

On 12/28/2012 04:04 PM, Arno Wagner wrote:
> I am thinking about a "basic LUKS setup" section for the FAQ 
> that is more in the nature of a mini-howto. Things like blanking
> a previously used partition before a LUKS install seem to be 
> not obvious to many people. Step-by-step instructions may help.

Wiping (whole) device (with some crypt random way) is still on TODO list.

But I believe that common signatures are wiped during LUKS format already
(we had several bugs related to this already) so it should never
happen that device contains ext4/swap/whatever signature parallel with
LUKS. (If so, please let me know, it is a bug.)

fsck can possibly use blkid and warn user
"Warning: device seems to contain xyz signature, do you really want...."
but this is feature for fsck (util-linux), not for cryptsetup.
(Anyway, I can ask util-linux maintainer later next year:)

Milan

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

On Fri, Dec 28, 2012 at 08:22:25PM +0100, Milan Broz wrote:
> On 12/28/2012 04:04 PM, Arno Wagner wrote:
> > I am thinking about a "basic LUKS setup" section for the FAQ 
> > that is more in the nature of a mini-howto. Things like blanking
> > a previously used partition before a LUKS install seem to be 
> > not obvious to many people. Step-by-step instructions may help.
> 
> Wiping (whole) device (with some crypt random way) is still on TODO list.

You can just wipe with zeros on the mapped device. They will be
encrypted after all. That could leak a tiny bit of information 
to an attacker that has access to the encrypted container
multiple times, but such an attacker can likely do far worse 
things anyways. If that is a concern, just use a different
master key for the zero-wipe, e.g. a one-time key derived in the 
same way as the LUKS master key. 

> But I believe that common signatures are wiped during LUKS format already
> (we had several bugs related to this already) so it should never
> happen that device contains ext4/swap/whatever signature parallel with
> LUKS. (If so, please let me know, it is a bug.)

Ext2 superblock signatures are all not wiped. Test I ran:

-----
# head -c 100M /dev/zero > test
# losetup /dev/loop0 test
# mke2fs -q /dev/loop0
# hd /dev/loop0 | grep "53 ef"
00000430  8b 7d de 50 00 00 18 00  53 ef 01 00 01 00 00 00 |.}.P....S.......|
00800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
# cryptsetup luksFormat /dev/loop0
[...]
# hd /dev/loop0 | grep "53 ef"
00009970  53 ef 3d 36 73 85 da 1e  20 cb bc 48 e9 e3 d9 b6  |S.=6s...
# ..H....|
00012c80  a2 f1 f6 53 ef b9 0c 30  75 60 6c c5 14 0b 6a 6b |...S...0u`l...jk|
00800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|

-----
The 5 superblock backups are still there. That should at least make 
e2fsck require some kind of override option. However, the primary 
superblock is just between the LUKS header and first keyslot. If I 
remember correctly, older versions of cryptsetup did not wipe that 
area (1.5.1 does). Maybe that is what happened here. 

As for the superblock backups, I would say wiping them should be 
part of a full device wipe to be done on a previosuly used partition. 
I just added a "LUKS Container Setup mini-HOWTO" in the FAQ as item
2.1 that explains this. (That this is a TODO for cryptsetup also
noted.)

> fsck can possibly use blkid and warn user
> "Warning: device seems to contain xyz signature, do you really want...."
> but this is feature for fsck (util-linux), not for cryptsetup.
> (Anyway, I can ask util-linux maintainer later next year:)

That would be nice. Things are pretty safe right now, but
further improvement is always welcome.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Milan Broz]

On 12/29/2012 08:06 AM, Arno Wagner wrote:
> On Fri, Dec 28, 2012 at 08:22:25PM +0100, Milan Broz wrote:

> Ext2 superblock signatures are all not wiped. Test I ran:

Backup signatures should not be problem, (from the fsck problem
POV, not from security/old data on disk POV of course).

Tools screams a lot if you want to use these only and primary
signature is missing.

Anyway, for wiping signature please suggest wipefs(8),
this tool is designed to wipe all known signatures.

(I am trying to avoid linking cryptsetup to libblkid, but
if this happens some time in future, cryptsetup can call wipefs
directly.)

IOW
 wipefs -a <device>

should destroy all known signatures to blkid
(by minimalistic writes, this is not full device
wipe, so it is very quick).

Milan

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

On Sat, Dec 29, 2012 at 10:05:12AM +0100, Milan Broz wrote:
> On 12/29/2012 08:06 AM, Arno Wagner wrote:
> > On Fri, Dec 28, 2012 at 08:22:25PM +0100, Milan Broz wrote:
> 
> > Ext2 superblock signatures are all not wiped. Test I ran:
> 
> Backup signatures should not be problem, (from the fsck problem
> POV, not from security/old data on disk POV of course).
> 
> Tools screams a lot if you want to use these only and primary
> signature is missing.

Yes, they should. I don't see this as a real problem.
 
> Anyway, for wiping signature please suggest wipefs(8),
> this tool is designed to wipe all known signatures.

Added. I also give long wipe instructions, but have now
wipefs as fast one.

Arno



> (I am trying to avoid linking cryptsetup to libblkid, but
> if this happens some time in future, cryptsetup can call wipefs
> directly.)
> 
> IOW
>  wipefs -a <device>
> 
> should destroy all known signatures to blkid
> (by minimalistic writes, this is not full device
> wipe, so it is very quick).
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Sven Eschenberg]

Hi Milan,

What happens though, if signatures are not accessible during luksFormat?
(Or alternatively, are not found, because they are misaligned from the
current setup's perspective?)

Scenario, create a md volume with 1.0 metadata (end of device), start md
device, do luks format.

Now, in intial unused state, the luks header and md metadata is visible.
While cryptsetup might be able to realize that the md device should first
be started, this might not be true for all tools (unfortunately). Possible
similiar scenarions with leftover superblocks etc. can surely be created.

I am aware this is a specific case due to the end of device policy of the
md metada v1.0. What I am trying to say is, not all cases can
automagically be resolved, sometimes the knowledge and interaction of an
admin might really be required. And for educated guessing, the admin needs
to be educated beforehand ;-).


Regards

-Sven


On Fri, December 28, 2012 20:22, Milan Broz wrote:
> On 12/28/2012 04:04 PM, Arno Wagner wrote:
>> I am thinking about a "basic LUKS setup" section for the FAQ
>> that is more in the nature of a mini-howto. Things like blanking
>> a previously used partition before a LUKS install seem to be
>> not obvious to many people. Step-by-step instructions may help.
>
> Wiping (whole) device (with some crypt random way) is still on TODO list.
>
> But I believe that common signatures are wiped during LUKS format already
> (we had several bugs related to this already) so it should never
> happen that device contains ext4/swap/whatever signature parallel with
> LUKS. (If so, please let me know, it is a bug.)
>
> fsck can possibly use blkid and warn user
> "Warning: device seems to contain xyz signature, do you really want...."
> but this is feature for fsck (util-linux), not for cryptsetup.
> (Anyway, I can ask util-linux maintainer later next year:)
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Milan Broz]

On 12/30/2012 09:42 AM, Sven Eschenberg wrote:
> Hi Milan,
> 
> What happens though, if signatures are not accessible during luksFormat?
> (Or alternatively, are not found, because they are misaligned from the
> current setup's perspective?)
> 
> Scenario, create a md volume with 1.0 metadata (end of device), start md
> device, do luks format.

Well, there are priorities but in fact these configurations need some
external info (or admin knowledge).

> Now, in intial unused state, the luks header and md metadata is visible.
> While cryptsetup might be able to realize that the md device should first
> be started, this might not be true for all tools (unfortunately). Possible
> similiar scenarions with leftover superblocks etc. can surely be created.

Yes, and in the MD format (end of device) case the problem repeats very often.

> I am aware this is a specific case due to the end of device policy of the
> md metada v1.0. What I am trying to say is, not all cases can
> automagically be resolved, sometimes the knowledge and interaction of an
> admin might really be required. And for educated guessing, the admin needs
> to be educated beforehand ;-).

Yes, fully agree. I can mention other situations, which can be configured
this way (LVM has several such undocumented scenarios) where you cannot
automatically say which signature is the first...

(I can write very long description about plans about "block device assembly"
library under util-linux project which should help to solve this, but I am
afraid that I will not work on this project anymore.)

And because we are on dmcrypt list - there is always need from security
(or paranoid ;) people to separate or hide metadata (e.g. LUKS header or
hidden container). In this situation you simply must know some info in advance
to properly activate such storage...

Milan

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

On Sun, Dec 30, 2012 at 10:39:43AM +0100, Milan Broz wrote:
> On 12/30/2012 09:42 AM, Sven Eschenberg wrote:
> > Hi Milan,
> > 
> > What happens though, if signatures are not accessible during luksFormat?
> > (Or alternatively, are not found, because they are misaligned from the
> > current setup's perspective?)
> > 
> > Scenario, create a md volume with 1.0 metadata (end of device), start md
> > device, do luks format.
> 
> Well, there are priorities but in fact these configurations need some
> external info (or admin knowledge).

Indeed. Just added the warning that previosuly used partitions should
be wiped to the man-page of cryptsetup. I also found that "wipefs"
does not remove matadata 0.90 signatures from md components (located
at the end. I still use them because I like kernel-level autodetection 
and my arrays are small), also added warning about that.
 
> > Now, in intial unused state, the luks header and md metadata is visible.
> > While cryptsetup might be able to realize that the md device should first
> > be started, this might not be true for all tools (unfortunately). Possible
> > similiar scenarions with leftover superblocks etc. can surely be created.
> 
> Yes, and in the MD format (end of device) case the problem repeats 
> very often.

Indeed. See above.

> > I am aware this is a specific case due to the end of device policy of the
> > md metada v1.0. What I am trying to say is, not all cases can
> > automagically be resolved, sometimes the knowledge and interaction of an
> > admin might really be required. And for educated guessing, the admin needs
> > to be educated beforehand ;-).
>
> Yes, fully agree. I can mention other situations, which can be configured
> this way (LVM has several such undocumented scenarios) where you cannot
> automatically say which signature is the first...

I think warning the user that anything previously used need to be
cleaned is enough. FAQ and man-page do that now. I think that is
enough. Those that do not read documentation will always find some
way to shoot themselves in the foot...

> (I can write very long description about plans about "block device
> assembly" library under util-linux project which should help to solve
> this, but I am afraid that I will not work on this project anymore.)

Some magic pressure-cooker you throw some partitions in and
get some assembled and runnign filesystems out? Sounds like
a nightmare to implement ;-)

> And because we are on dmcrypt list - there is always need from security
> (or paranoid ;) people to separate or hide metadata (e.g.  LUKS header or
> hidden container).  In this situation you simply must know some info in
> advance to properly activate such storage...

Security requires understanding what you are doing or at least reading
the documentation carefully (it it is any good). For example, I 
recently found out that there are people that run TrueCrypt on Windows 
whith hibernation active and the hibernation file not on an encrypted
device. That is a complete fail, as the encryption keys then go into
the hiberfile. (The documentation warns about this.) Seems you can 
even buy software that recovers the keys automatically.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Sven Eschenberg]

On Sun, December 30, 2012 11:53, Arno Wagner wrote:
> On Sun, Dec 30, 2012 at 10:39:43AM +0100, Milan Broz wrote:
>> On 12/30/2012 09:42 AM, Sven Eschenberg wrote:
>> > Hi Milan,
>> >
>> > What happens though, if signatures are not accessible during
>> luksFormat?
>> > (Or alternatively, are not found, because they are misaligned from the
>> > current setup's perspective?)
>> >
>> > Scenario, create a md volume with 1.0 metadata (end of device), start
>> md
>> > device, do luks format.
>>
>> Well, there are priorities but in fact these configurations need some
>> external info (or admin knowledge).
>
> Indeed. Just added the warning that previosuly used partitions should
> be wiped to the man-page of cryptsetup. I also found that "wipefs"
> does not remove matadata 0.90 signatures from md components (located
> at the end. I still use them because I like kernel-level autodetection
> and my arrays are small), also added warning about that.

Seems like the most reasonable solution to add this bit to the man page.
btw, it is called wipefs, not wipeall metadata ;-) (SCNR). I think we can
agree, that if a reasonable person gets reminded to wipe problematic data,
the person can take care of this. I think mdadm --zero-superblock will
work for 0.9 (Only used it on v1.x versions so far).

>
>> > Now, in intial unused state, the luks header and md metadata is
>> visible.
>> > While cryptsetup might be able to realize that the md device should
>> first
>> > be started, this might not be true for all tools (unfortunately).
>> Possible
>> > similiar scenarions with leftover superblocks etc. can surely be
>> created.
>>
>> Yes, and in the MD format (end of device) case the problem repeats
>> very often.
>
> Indeed. See above.
>
>> > I am aware this is a specific case due to the end of device policy of
>> the
>> > md metada v1.0. What I am trying to say is, not all cases can
>> > automagically be resolved, sometimes the knowledge and interaction of
>> an
>> > admin might really be required. And for educated guessing, the admin
>> needs
>> > to be educated beforehand ;-).
>>
>> Yes, fully agree. I can mention other situations, which can be
>> configured
>> this way (LVM has several such undocumented scenarios) where you cannot
>> automatically say which signature is the first...
>
> I think warning the user that anything previously used need to be
> cleaned is enough. FAQ and man-page do that now. I think that is
> enough. Those that do not read documentation will always find some
> way to shoot themselves in the foot...

As said before, I second that.

>
>> (I can write very long description about plans about "block device
>> assembly" library under util-linux project which should help to solve
>> this, but I am afraid that I will not work on this project anymore.)
>
> Some magic pressure-cooker you throw some partitions in and
> get some assembled and runnign filesystems out? Sounds like
> a nightmare to implement ;-)

Or a nightmare to use if anything backfires ;-).

>
>> And because we are on dmcrypt list - there is always need from security
>> (or paranoid ;) people to separate or hide metadata (e.g.  LUKS header
>> or
>> hidden container).  In this situation you simply must know some info in
>> advance to properly activate such storage...
>
> Security requires understanding what you are doing or at least reading
> the documentation carefully (it it is any good). For example, I
> recently found out that there are people that run TrueCrypt on Windows
> whith hibernation active and the hibernation file not on an encrypted
> device. That is a complete fail, as the encryption keys then go into
> the hiberfile. (The documentation warns about this.) Seems you can
> even buy software that recovers the keys automatically.
>
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> 9718
> ----
> One of the painful things about our time is that those who feel certainty
> are stupid, and those with any imagination and understanding are filled
> with doubt and indecision. -- Bertrand Russell
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

-Sven

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Milan Broz]

On 12/30/2012 01:08 PM, Sven Eschenberg wrote:
>> I also found that "wipefs"
>> does not remove matadata 0.90 signatures from md components (located
>> at the end. I still use them because I like kernel-level autodetection
>> and my arrays are small), also added warning about that.

Usual util-linux maintainer response is "send a patch" :-)

wipefs must work (e.g. anaconda installer depends on the proper sig. erase)
so it is a bug somewhere.

Do you have reproducer? (only 0.9 metadata end-of-disk format?)

Milan

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

On Sun, Dec 30, 2012 at 01:25:46PM +0100, Milan Broz wrote:
> On 12/30/2012 01:08 PM, Sven Eschenberg wrote:
> >> I also found that "wipefs"
> >> does not remove matadata 0.90 signatures from md components (located
> >> at the end. I still use them because I like kernel-level autodetection
> >> and my arrays are small), also added warning about that.
> 
> Usual util-linux maintainer response is "send a patch" :-)
> 
> wipefs must work (e.g. anaconda installer depends on the proper sig. erase)
> so it is a bug somewhere.
> 
> Do you have reproducer? (only 0.9 metadata end-of-disk format?)

Reproduce with (adjust loop2 and md12 numbers as needed):
------
head -c 1M /dev/zero > t
losetup /dev/loop2 t
mdadm --create --metadata=0.90 --force -l 1 -n 1 /dev/md12 /dev/loop2
mdadm --stop /dev/md12
mdadm --examine /dev/loop2
  --> Raid componend with intact magic
wipefs /dev/loop2
mdadm --examine /dev/loop2
  --> same as above, RAID signature still there
------

Version (Debian stable): util-linux: 2.17.2-9

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Emily Williams]

[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]

On Fri, Dec 28, 2012 at 10:04 AM, Arno Wagner <arno@wagner.name> wrote:

> On Fri, Dec 28, 2012 at 03:46:45PM +0100, Sven Eschenberg wrote:
> > I think these are the 2 most common sources, when something like this
> > happens.
> >
> > It would be interesting to know though:
> >
> > Did the device ever hold an ext filesystem?
> > What was done before creating the luks container?
>

The disk before luksFormat was a new-out-of-the-box WD 4TB "My Book"
external USB 3 hard drive. Nothing at all had been done to it before being
attached to the already-running system. The already-running system was
running Debian GNU/Linux Squeeze on x86_64.

I assume it had FAT32 formatting before the luksFormat, but I don't know
for sure. But I am 100% sure it wouldn't have had any kind of extX
formatting.


>  > I wonder how fsck checks for a superblock. I still assume, that chances
> of
> > having encrypted data in the right block on disk looking like a correct
> > ext-superblock is next to zero.
>
> The ext2 superblock magic number seems to be 0xEF53. That is a bit
> short but still only gives something like 1 in 65536 probability of
> misdetection in encrypted data. I think we can rule that out
> for the moment.


That actually seems like a pretty big chance to me. esp. if a hard drive
manufacturer happens to have shipped a hard drive model where each hard
drive has this problem.

I wonder how many different models of hard drive are produced every year /
from that what the chances are of this being a "problem by default" on a
large number of hard drives over say a 10-year period.

Is there some reason using, say, an order of magnitude (or even two orders)
more data for a magic number would cause some kind of issue? The actual
amount of data vs. the size of any modern hard drive would seem to me to be
pretty trivial.

Thanks re: wipefs (in another person's response), seems like a better and
more complete solution than what I did, which was something like dd
if=/dev/zero of=/dev/sdX count=10000. Although based on other people it
sounds like doing wipefs + dd at start of both drive and partiton + dd at
end of both drive and partition (which I'm guessing would just need to be
calculated and then a seek/skip option to dd used, as I can't see any
option that will let dd work backwards) would be the most paranoid /
complete way to go.

One thing no one has mentioned that may add an additional bit of safety -
while researching this, I found someone saying that the filesystem type as
set in [gf]disk is always ignored by Linux. (Perhaps this only holds true
for non-"fd "partitions?)

So I've taken to setting my encrypted partitions to "NetBSD Encrypted"
(a905), so when I look at the partition tables I'm reminded that there
actually isn't a Linux filesystem on the device itself, but rather
something that is encrypted that becomes a Linux filesystem via
/dev/mapper/X after cryptosetup luksOpen happens.

(I don't use NetBSD, so no chance of confusion there :-)

[-- Attachment #2: Type: text/html, Size: 3782 bytes --]

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Matthias Schniedermeyer]

On 30.12.2012 11:59, Emily Williams wrote:
> 
> So I've taken to setting my encrypted partitions to "NetBSD Encrypted"
> (a905), so when I look at the partition tables I'm reminded that there
> actually isn't a Linux filesystem on the device itself, but rather
> something that is encrypted that becomes a Linux filesystem via
> /dev/mapper/X after cryptosetup luksOpen happens.

I create a dummy partition with type 'da' (Non-FS-Data) on my HDDs.
Altough 0 (Empty) sounds nice too. ;-)

I say dummy partition because i don't actually use the partition for 
anything. It's only there to stop my encryption init-script, so that i 
don't accidentally kill an already initialized HDD (or one of the 
system-HDDs) in case i fat-fingered the device-name.




-- 

Matthias

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Arno Wagner]

On Sun, Dec 30, 2012 at 11:59:56AM -0500, Emily Williams wrote:
> On Fri, Dec 28, 2012 at 10:04 AM, Arno Wagner <arno@wagner.name> wrote:
> 
> > On Fri, Dec 28, 2012 at 03:46:45PM +0100, Sven Eschenberg wrote:
> > > I think these are the 2 most common sources, when something like this
> > > happens.
> > >
> > > It would be interesting to know though:
> > >
> > > Did the device ever hold an ext filesystem?
> > > What was done before creating the luks container?
> >
> 
> The disk before luksFormat was a new-out-of-the-box WD 4TB "My Book"
> external USB 3 hard drive. Nothing at all had been done to it before being
> attached to the already-running system. The already-running system was
> running Debian GNU/Linux Squeeze on x86_64.
> 
> I assume it had FAT32 formatting before the luksFormat, but I don't know
> for sure. But I am 100% sure it wouldn't have had any kind of extX
> formatting.

With 4TB, it should have had an NTFS filesystem on it.
 
> >  > I wonder how fsck checks for a superblock. I still assume, that chances
> > of
> > > having encrypted data in the right block on disk looking like a correct
> > > ext-superblock is next to zero.
> >
> > The ext2 superblock magic number seems to be 0xEF53. That is a bit
> > short but still only gives something like 1 in 65536 probability of
> > misdetection in encrypted data. I think we can rule that out
> > for the moment.
> 
> 
> That actually seems like a pretty big chance to me. esp. if a hard drive
> manufacturer happens to have shipped a hard drive model where each hard
> drive has this problem.

It is not. First, the signature would need to turn up in the encrypted 
data and that is different for each LUKS container. In addition,
the first superblock is in an area that newer versions of cryptsetup
overwrite with zeros.
 
> I wonder how many different models of hard drive are produced every year /
> from that what the chances are of this being a "problem by default" on a
> large number of hard drives over say a 10-year period.

Basically none. The HDD vendors do not write random data to their drives.
They either come zeroed of with a filesystem on them (USB drives).

> Is there some reason using, say, an order of magnitude (or even two orders)
> more data for a magic number would cause some kind of issue? The actual
> amount of data vs. the size of any modern hard drive would seem to me to be
> pretty trivial.

I agreee, that ist is a bit short. Anybody with a crypto background would
want at least 128 bit (16 bytes) and better 256 bit for magic numbers.
But it is out-of-scope for cryptsetup and I doubt we can have much
influence on the ext<x> designers.
 
> Thanks re: wipefs (in another person's response), seems like a better and
> more complete solution than what I did, which was something like dd
> if=/dev/zero of=/dev/sdX count=10000. 

No, the zero overwrite is better. Its only problem is that it is slow.

> Although based on other people it
> sounds like doing wipefs + dd at start of both drive and partiton + dd at
> end of both drive and partition (which I'm guessing would just need to be
> calculated and then a seek/skip option to dd used, as I can't see any
> option that will let dd work backwards) would be the most paranoid /
> complete way to go.

The most paranoid is one complete zero-overwrite. 

> One thing no one has mentioned that may add an additional bit of safety -
> while researching this, I found someone saying that the filesystem type as
> set in [gf]disk is always ignored by Linux. (Perhaps this only holds true
> for non-"fd "partitions?)

No idea. But that way madness lies, I think.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Sven Eschenberg]

On Sun, December 30, 2012 20:45, Arno Wagner wrote:
> On Sun, Dec 30, 2012 at 11:59:56AM -0500, Emily Williams wrote:
>> On Fri, Dec 28, 2012 at 10:04 AM, Arno Wagner <arno@wagner.name> wrote:
>>
>> > On Fri, Dec 28, 2012 at 03:46:45PM +0100, Sven Eschenberg wrote:
>> > > I think these are the 2 most common sources, when something like
>> this
>> > > happens.
>> > >
>> > > It would be interesting to know though:
>> > >
>> > > Did the device ever hold an ext filesystem?
>> > > What was done before creating the luks container?
>> >
>>
>> The disk before luksFormat was a new-out-of-the-box WD 4TB "My Book"
>> external USB 3 hard drive. Nothing at all had been done to it before
>> being
>> attached to the already-running system. The already-running system was
>> running Debian GNU/Linux Squeeze on x86_64.
>>
>> I assume it had FAT32 formatting before the luksFormat, but I don't know
>> for sure. But I am 100% sure it wouldn't have had any kind of extX
>> formatting.
>
> With 4TB, it should have had an NTFS filesystem on it.

AFAIK as of 2TB it's NTFS with the my book and the 4 TB one certainly has
a GPT aswell.

>
>> >  > I wonder how fsck checks for a superblock. I still assume, that
>> chances
>> > of
>> > > having encrypted data in the right block on disk looking like a
>> correct
>> > > ext-superblock is next to zero.
>> >
>> > The ext2 superblock magic number seems to be 0xEF53. That is a bit
>> > short but still only gives something like 1 in 65536 probability of
>> > misdetection in encrypted data. I think we can rule that out
>> > for the moment.
>>
>>
>> That actually seems like a pretty big chance to me. esp. if a hard drive
>> manufacturer happens to have shipped a hard drive model where each hard
>> drive has this problem.
>
> It is not. First, the signature would need to turn up in the encrypted
> data and that is different for each LUKS container. In addition,
> the first superblock is in an area that newer versions of cryptsetup
> overwrite with zeros.
>
>> I wonder how many different models of hard drive are produced every year
>> /
>> from that what the chances are of this being a "problem by default" on a
>> large number of hard drives over say a 10-year period.
>
> Basically none. The HDD vendors do not write random data to their drives.
> They either come zeroed of with a filesystem on them (USB drives).
>
>> Is there some reason using, say, an order of magnitude (or even two
>> orders)
>> more data for a magic number would cause some kind of issue? The actual
>> amount of data vs. the size of any modern hard drive would seem to me to
>> be
>> pretty trivial.
>
> I agreee, that ist is a bit short. Anybody with a crypto background would
> want at least 128 bit (16 bytes) and better 256 bit for magic numbers.
> But it is out-of-scope for cryptsetup and I doubt we can have much
> influence on the ext<x> designers.

Wouldn't that be ext5 then anyway, since the change is incompatible
(touching the main metadata)with current versions? That feels liek
ressurecting the dead ;-).

>
>> Thanks re: wipefs (in another person's response), seems like a better
>> and
>> more complete solution than what I did, which was something like dd
>> if=/dev/zero of=/dev/sdX count=10000.
>
> No, the zero overwrite is better. Its only problem is that it is slow.
>
>> Although based on other people it
>> sounds like doing wipefs + dd at start of both drive and partiton + dd
>> at
>> end of both drive and partition (which I'm guessing would just need to
>> be
>> calculated and then a seek/skip option to dd used, as I can't see any
>> option that will let dd work backwards) would be the most paranoid /
>> complete way to go.
>
> The most paranoid is one complete zero-overwrite.

Most paranoid and 'safe' way.

>
>> One thing no one has mentioned that may add an additional bit of safety
>> -
>> while researching this, I found someone saying that the filesystem type
>> as
>> set in [gf]disk is always ignored by Linux. (Perhaps this only holds
>> true
>> for non-"fd "partitions?)
>
> No idea. But that way madness lies, I think.

Well it is not a filesystem type, but partition type. Then again, as linux
can access a whole bunch of types (including different label styles) this
could at most be checked within tools (i.e. mdadm ignores everything
except raid partition types). On the other hand, it is perfectly okay to
not slice the disk and put LVM, MD(raid), luks or even a fs directly onto
the device. If that is a wise decision is another question though. Think
of the GPT, where usually a protective mbr is created, so that low level
tools keep their finger off what they don't know, partition in general
could be handled by tools this way.

Speaking of which, there's GUIDs for LVM, RAID, FSDATA but not for
LUKS/cryptsetup so far.

>
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> 9718
> ----
> One of the painful things about our time is that those who feel certainty
> are stupid, and those with any imagination and understanding are filled
> with doubt and indecision. -- Bertrand Russell
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

-Sven

Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Richard]

On Sun, Dec 30, 2012 at 11:59:56AM -0500, Emily Williams wrote:
> On Fri, Dec 28, 2012 at 10:04 AM, Arno Wagner <arno@wagner.name> wrote:


> >  > I wonder how fsck checks for a superblock. I still assume, that chances
> > of
> > > having encrypted data in the right block on disk looking like a correct
> > > ext-superblock is next to zero.
> >
> > The ext2 superblock magic number seems to be 0xEF53. That is a bit
> > short but still only gives something like 1 in 65536 probability of
> > misdetection in encrypted data. I think we can rule that out
> > for the moment.
> 
> 
> That actually seems like a pretty big chance to me. esp. if a hard drive
> manufacturer happens to have shipped a hard drive model where each hard
> drive has this problem.

fsck will not blindly trust a random superblock signature. All values inside
the superblock are checked if they are plausible. It will scream loudly if
superblock is screwed. The chance it will accept a random sector as valid
superblock is very very close to zero.


Richard

---
Name and OpenPGP keys available from pgp key servers