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

Emily Williams emilyw at MIT.EDU
Sun Dec 30 17:59:56 CET 2012


On Fri, Dec 28, 2012 at 10:04 AM, Arno Wagner <arno at 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 :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20121230/7f700898/attachment.html>


More information about the dm-crypt mailing list