linux-kernel - Re: RO mount of ext4 filesystem causes writes

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJU5HN3bmXR3FvzE@glitch>
Date:   Thu, 22 Jun 2023 23:18:04 -0700
From:   Sean Greenslade <sean@...ngreenslade.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Bagas Sanjaya <bagasdotme@...il.com>, linux-ext4@...r.kernel.org,
        Ye Bin <yebin10@...wei.com>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Regressions <regressions@...ts.linux.dev>
Subject: Re: RO mount of ext4 filesystem causes writes

On Fri, Jun 23, 2023 at 12:46:11AM -0400, Theodore Ts'o wrote:
> On Fri, Jun 23, 2023 at 08:06:02AM +0700, Bagas Sanjaya wrote:
> > 
> > No reply so far from the culprit author (Ye Bin) nor from Ted. Can
> > you help in this case?
> 
> There's been no reply because I haven't been able to replicate it, and
> I didn't have the time do enough work to convince myself the report
> was bogus.  At this point, I have spent time trying to reproduce it,
> and I've had no luck.
> 
> So, unless you can give me a simple set of reproduction instructions,
> I'm going to have to treat this report is invalid.
> 
> Regards,
> 
> 						- Ted
> 
> Note: this test was done using kvm-xfstests which can be found
> https://github.com/tytso/xfstests-bld using the install-kconfig and
> the kbuild script that can also be found in this report.  So if you
> want to play along from home, feel free.  :-)
> 
> 
> root@...-xfstests:~# mkfs.ext4 /dev/vdc
> mke2fs 1.47.0 (5-Feb-2023)
> Discarding device blocks: done                            
> Creating filesystem with 1310720 4k blocks and 327680 inodes
> Filesystem UUID: fe434060-6731-4b40-a94a-3a8517df0660
> Superblock backups stored on blocks: 
>         32768, 98304, 163840, 229376, 294912, 819200, 884736
> 
> Allocating group tables: done                            
> Writing inode tables: done                            
> Creating journal (16384 blocks): done
> Writing superblocks and filesystem accounting information: done 
> 
> root@...-xfstests:~# md5sum /dev/vdc
> fd38f9f8476ad63a744d179846ee7e18  /dev/vdc
> root@...-xfstests:~# mount -o ro /dev/vdc /mnt
> [  472.893614] EXT4-fs (vdc): orphan cleanup on readonly fs
> [  472.894022] EXT4-fs (vdc): mounted filesystem fe434060-6731-4b40-a94a-3a8517df0660 ro with ordered data mode. Quota mode: none.
> root@...-xfstests:~# umount /mnt
> [  475.698053] EXT4-fs (vdc): unmounting filesystem fe434060-6731-4b40-a94a-3a8517df0660.
> root@...-xfstests:~# md5sum /dev/vdc
> fd38f9f8476ad63a744d179846ee7e18  /dev/vdc
> 
> Hmm.... OK, let's try it with LUKS, even though that *really*
> shouldn't make a difference.  The cryptsetup lukeFormat and mkfs.ext4
> steps are skipped here.  Also, note that I had to manually edit the
> .config file to enable CONFIG_DM_CRYPT, since I dm_crypt is used by
> xfstests, so my install-kconfig script doesn't enable CONFIG_DM_CRYPT.
> 
> 
> root@...-xfstests:~# uname -a
> Linux kvm-xfstests 6.4.0-rc6-xfstests-lockdep #200 SMP PREEMPT_DYNAMIC Fri Jun 23 00:33:39 EDT 2023 x86_64 GNU/Linux
> 
> root@...-xfstests:~# md5sum /dev/vdc
> 28b75cc094e1e2a62ac25a730fc1dfee  /dev/vdc
> root@...-xfstests:~# cryptsetup luksOpen /dev/vdc test
> Enter passphrase for /dev/vdc: 
> root@...-xfstests:~# mount -o ro /dev/mapper/test /mnt
> [  812.073771] EXT4-fs (dm-0): orphan cleanup on readonly fs
> [  812.074306] EXT4-fs (dm-0): mounted filesystem ac3f76f1-da0a-426e-85b2-08526afb2224 ro with ordered data mode. Quota mode: none.
> root@...-xfstests:~# umount /mnt
> [  814.383016] EXT4-fs (dm-0): unmounting filesystem ac3f76f1-da0a-426e-85b2-08526afb2224.
> root@...-xfstests:~# cryptsetup luksClose /dev/mapper/test
> [  830.001992] dm-0: detected capacity change from 10452992 to 0
> root@...-xfstests:~# md5sum /dev/vdc
> 28b75cc094e1e2a62ac25a730fc1dfee  /dev/vdc

Hi, Ted. Thanks for taking the time to look into this.

I perhaps should have been more explicit in my report. The issue is not
that the image is any different after the mount; indeed, the md5sums are
identical before and after on my machine as well. The issue is that
something is issuing writes to the backing image, which bumps the mtime
of the backing image. When handling the images with rsync, a difference
in mtime causes the whole image to need to be read.

See this flow:

$ stat image.block | grep Modify
Modify: 2023-06-22 23:00:15.211379972 -0700

# cryptsetup luksOpen image.block t2 && mount -o ro /dev/mapper/t2 /mnt/t2
# umount /mnt/t2 && cryptsetup luksClose t2

$ stat image.block | grep Modify
Modify: 2023-06-22 23:03:56.141139649 -0700


The regression is the mtime bumping behavior, which doesn't happen prior
to the eee00237 commit.

Thanks,

--Sean