linux-kernel - strange pagecache behaviour with dm-crypt on raid1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1281046400.22005.177.camel@morgoth.abyss.4t2.com>
Date:	Fri, 06 Aug 2010 00:13:20 +0200
From:	Tom Weber <l_linux-kernel@...l2news.4t2.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: strange pagecache behaviour with dm-crypt on raid1

I stumbled upon this while setting up a new System with

dm-crypt (/dev/mapper/md3dec) on top of 
/dev/md3 as raid1 (/dev/sd[ab]5)

and initially filling /dev/mapper/md3dec with zeros
dd if=/dev/zero of=/dev/mapper/md3dec bs=100M

i was curious about how far dd had progressed, so i played around with

dd if=/dev/md3 bs=1M count=1 skip=xx  | hexdump

to see if there were still zeros or already crypted data.

now say i found crypted data at offset xx=390000 and zeros at xx=400000
this dd command would always return zeros at 400000 even if the
originial filling dd progressed beyond 400000 (dd at 410000 would give
my crypted data).

up until freeing the page cache with
echo 1 > /proc/sys/vm/drop_caches
a dd at 400000 would always give me zeros (the first result).

is this intended behaviour or is there something going wrong?

this is 2.6.35-vs2.3.0.36.31 (vanilla + vserver patch) on x86_64.

  Tom

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/