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
| ||
|
Date: Mon, 19 Oct 2009 09:40:37 +0900 From: Akira Fujita <a-fujita@...jp.nec.com> To: Peng Tao <bergwolf@...il.com> CC: ext4 development <linux-ext4@...r.kernel.org>, Kazuya Mio <k-mio@...jp.nec.com>, "Theodore Ts'o" <tytso@....edu> Subject: Re: donor file data inconsistent after EXT4_IOC_MOVE_EXT Hi Peng, This is a known issue, and I sent a patch to linux-ext4 2 weeks ago. Unfortunately it is not included in the ext4 patch queue yet. http://marc.info/?l=linux-ext4&m=125447192709338&w=2 Would you retry your test case with above my patch? Regards, Akira Fujita Peng Tao wrote: > Hi, > > As I am looking more closely to the EXT4_IOC_MOVE_EXT ioctl, I found a > problem. The iotcl exchanges the block layout of the orig file and donor file > and then writes out orig file data to orig file's new blocks. > After the ioctl, the donor file would have the blocks previously owned by the > orig file. But it turns out inconsistent. > > A simple test case for revealing the bug: > The program a.out is calling EXT4_IOC_MOVE_EXT against argv[1] (as orig file) > and argv[2] (as donor file) and move_data.len = argv[1]'s block count. > > And I am running mainline kernel 2.6.32-rc3 and the ext4 partition is mounted > in ordered mode with default settings, if you are interested. > > [bergwolf@...e_extent]$sh test-5.sh > make full-img > ========create full.img======== > dd if=/home/bergwolf/vm/OpenSolaris200805.iso of=full-1.img bs=1M count=30 > 30+0 records in > 30+0 records out > 31457280 bytes (31 MB) copied, 0.0847457 s, 371 MB/s > dd if="/home/bergwolf/vm/WINXP_EN_PRO_SP3_MSDN/WinXp+Sp3 enu.iso" of=full-2.img bs=1M count=30 > 30+0 records in > 30+0 records out > 31457280 bytes (31 MB) copied, 0.0664263 s, 474 MB/s > md5sum full-1.img full-2.img > 4f47bee75290d094c94f8a7cb2075c69 full-1.img > 9e35330146a610d0aa2fab1d16aa2b09 full-2.img > ./a.out full-1.img full-2.img > md5sum full-1.img full-2.img > 4f47bee75290d094c94f8a7cb2075c69 full-1.img > 9e35330146a610d0aa2fab1d16aa2b09 full-2.img <---- wrong content > [bergwolf@...e_extent]$cd > [bergwolf@~]$sudo umount /other/ > [bergwolf@~]$sudo mount /other/ > [bergwolf@~]$cd - > /other/test/move_extent > [bergwolf@...e_extent]$md5sum full-1.img full-2.img > 4f47bee75290d094c94f8a7cb2075c69 full-1.img > 4f47bee75290d094c94f8a7cb2075c69 full-2.img <---- right result > > I verified that the bug is because of the pagecache hit in the vfs_read(), > via the following test case: > > [bergwolf@...e_extent]$sudo sh test-4.sh > make full-img > ========create full.img======== > dd if=/home/bergwolf/vm/OpenSolaris200805.iso of=full-1.img bs=1M count=30 > 30+0 records in > 30+0 records out > 31457280 bytes (31 MB) copied, 0.115624 s, 272 MB/s > dd if="/home/bergwolf/vm/WINXP_EN_PRO_SP3_MSDN/WinXp+Sp3 enu.iso" of=full-2.img bs=1M count=30 > 30+0 records in > 30+0 records out > 31457280 bytes (31 MB) copied, 1.16482 s, 27.0 MB/s > md5sum full-1.img full-2.img > 4f47bee75290d094c94f8a7cb2075c69 full-1.img > 9e35330146a610d0aa2fab1d16aa2b09 full-2.img > sync > echo 1 > /proc/sys/vm/drop_caches <------- this drops all pagecaches, FYI > ./a.out full-1.img full-2.img > md5sum full-1.img full-2.img > 4f47bee75290d094c94f8a7cb2075c69 full-1.img > 4f47bee75290d094c94f8a7cb2075c69 full-2.img > > IIUC, this is because pagecache not uptodate. FWIW, EXT4_IOC_MOVE_EXT > calls ext4_ext_invalidate_cache() to prevent later access to donor file reading > old data. But if the data is already in the pagecache (in which case, > ext4_get_blocks() won't be called), vfs_read will still read the old data. > But I don't know if there is a way to discard all pagecache for a specific > inode. I tried to write something similar to ext4_da_block_invalidatepages() > and ClearPageUptodate() on each page found in the mapping address, > but it didn't work. > > So am I missing anything? And any hints how to force the following vfs_read() > to read from disk? > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists