linux-kernel - Re: Preserving a rev 0.0 ext2 filesystem

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: <3A06C183-19FF-48B3-9C49-60353BEC9DB8@dilger.ca>
Date:   Sat, 12 Jan 2019 17:20:24 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>, Jan Kara <jack@...e.com>
Cc:     Theodore Tso <tytso@....edu>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Preserving a rev 0.0 ext2 filesystem

On Jan 12, 2019, at 2:43 AM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> 
> Hi Ted,
> 
> I'm still regularly using a Linux rev 0.0 ext2 filesystem as a  ramdisk
> on m68k, containing mid-90's binaries, from right after the a.out-to-ELF
> transition, so I notice if someone breaks old syscall support.
> 
> Recently I wanted to change /dev/console on that ramdisk from a symlink
> to chardev 5 0.  Unfortunately I cannot mount it, without it being
> upgraded automatically to a rev 1.0 ext2 filesystem.  Apparently the
> kernel has been doing that upgrade for ages.
> 
> Do you have a suggestion how to make that change, while preserving the
> ext2 revision?

It looks like there is a "gratuitous" call to ext4_update_dynamic_rev() in the
mount path that is left over from when ext3 always set the INCOMPAT_RECOVER and
COMPAT_HAS_JOURNAL features on every mount.  With the "nojournal" mount option
these are no longer needed.  You could probably just remove this call with no ill
effects, or better yet apply the patch that I'll push shortly to this effect.
It's been there since the start of git history (2.6.12-rc2) in the ext3 code
that was later copied to become ext4, but digging through my email archives it
looks like adding the call to "ext3_update_fs_rev()" was actually one of my first
patches against the original ext3 code "[Ext2-devel] Re: RECOVER INCOMPAT flag",
dated Nov 18, 2000.

The only thing ext4_update_dynamic_rev() does is update s_rev_level, and set
s_first_ino and s_inode_size on disk to the values that the kernel already
assumes to be true (newer kernels can use different values).  Those fields are
also set in memory later during the mount, so the rest of the code should work
OK (I haven't tested). This will probably only affect your filesysem (everything
else in the last 20 years uses EXT2_DYNAMIC_REV) so it won't be much of a change.

The "real" ext2 code looks like it does not call ext2_update_dynamic_rev() for
every filesystem during mount, only if you write a file > 2GB in size, so it would
also be possible to mount with the ext2.ko driver (if your kernel provides it).
There looks like a minor bug in ext2 that it doesn't call ext2_update_dynamic_rev()
if an xattr is stored on the filesystem and it sets EXT2_FEATURE_COMPAT_EXT_ATTR
in ext2_xattr_update_super_block().  However, nobody noticed in since xattrs landed.

In any case, it would be fun to give my patch a try to see if it allows your old
filesystem to be mounted and modified with a modern kernel and then mounted on
the old kernel again, as a testament to ext2/ext4 feature compatibility.

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)