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: <20150903193608.GD10390@birch.djwong.org>
Date:	Thu, 3 Sep 2015 12:36:08 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	Richard Yao <ryao@...too.org>
Cc:	Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Raymond Jennings <shentino@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Theodore Ts'o" <tytso@....edu>, Albino B Neto <bino@...eup.net>
Subject: Re: [GIT PULL] Ext3 removal, quota & udf fixes

On Thu, Sep 03, 2015 at 07:16:19PM +0000, Richard Yao wrote:
> On Thu, Sep 03, 2015 at 11:36:57AM -0700, Darrick J. Wong wrote:
> > On Thu, Sep 03, 2015 at 06:22:25PM +0000, Richard Yao wrote:
> > > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> > > `mount -t ext3 /dev/$DEVICE $MNT`?
> > > 
> > > This should fail with the ext3 driver, but it looks like it will work fine with
> > > CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
> > > not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> > > derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> > > suspicion, but I imagine there are others on the list that could trivially check
> > > this.
> > 
> > On 4.2 with CONFIG_EXT4_USE_FOR_EXT23:
> > 
> > # mke2fs -T ext4 /dev/sda
> > # mount /dev/sda /mnt -t ext3
> > mount: wrong fs type, bad option, bad superblock on /dev/sda,
> >        missing codepage or helper program, or other error
> >        In some cases useful info is found in syslog - try
> >        dmesg | tail  or so
> > 
> > # lsmod|grep ext 
> > ext4                  630784  0 
> > jbd2                  126976  1 ext4
> > mbcache                20480  1 ext4
> > # dmesg
> > <snip>
> > [74559.632979] EXT4-fs (sda): couldn't mount as ext3 due to feature incompatibilities
> > 
> > > Also, new kernels are typically drop-in replacements on older userlands. An edge
> > > case that no one appears to have mentioned is the possibility of using a newer
> > > kernel on an older system where the initramfs generator might only include ext3,
> > > which this would break. It might not be terrible to write a small dummy ext3
> > > module whose only purpose is to depend on ext4 and load it into the kernel on
> > > those systems. That way initramfs software that properly grabs module
> > > dependencies will include the ext4 module and `modprobe ext3` will do what it
> > 
> > Well, if it goes looking for ext3.ko directly it will fail, but...
> > 
> > # modinfo ext3
> > filename:       /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> > license:        GPL
> > description:    Fourth Extended Filesystem
> > author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
> > alias:          fs-ext4
> > alias:          ext3
> > alias:          fs-ext3
> > <snip>
> > 
> > I don't know about RHEL initrd scripts, but Ubuntu's use some modprobe trickery
> > which ensures that it picks up the correct ext4.ko.  It does something similar
> > to this:
> > 
> > # modprobe --ignore-install --quiet --show-depends ext3 | sed -e 's/^insmod //g'
> > /lib/modules/4.2.0-mcsum/kernel/fs/mbcache.ko 
> > /lib/modules/4.2.0-mcsum/kernel/fs/jbd2/jbd2.ko 
> > /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> > 
> > to pick up the modules for the initramfs.  Not sure what the other distros
> > do, though.
> 
> Unfortunately, the genkernel team was not aware of this when it wrote support
> for including kernel modules and I suspect others writing initramfs archive
> generators did not either.
> 
> https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh#n638
> https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_moddeps.sh
> https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/modules_load
> 
> The way that works is that the module names are specified in a MODULES_*
> variable and then we search for dependencies based on what is specified in
> modules.dep. If you have an old enough version of the initramfs genreator, ext4
> is not specified and it will not recognize the alias.
> 
> I admit that this is likely a very rare edge case. I do not feel too strongly
> about breaking the older initramfs software. I just wanted to make sure others
> knew that they were.

Hmmm, is there no modules.alias on Gentoo?  That seems unlikely to me, but
I haven't run it in a while.  It's unfortunate that it doesn't get parsed
as part of initrd generation.

<shrug> I guess the initrd would break if you were trying to install a 4.3
kernel onto a pre-2010ish Gentoo rootfs, unless that file gets updated(?)

--D

> 
> > > always did in terms of making ext3 file systems mountable. I suppose that we
> > > could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> > > to avoid surprises, a dummy module seems reasonable.
> > > 
> > > These are the only two things that I see preventing ext4 from being a drop-in
> > > replacement for ext3.
> > > 
> > > That said, my only connection with ext3/ext4 is that I am one of the genkernel
> > > developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> > > my opinion might not matter much here, but I am also in favor of killing ext3 in
> > > favor of CONFIG_EXT4_USE_FOR_EXT23.
> > 
> > :)
> > 
> > --D
> > 
> > > --
> > > 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
> --
> 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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ