Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 16 Jun 2023 17:49:53 +0200
From:   Jan Kara <jack@suse.cz>
To:     Dave Chinner <david@fromorbit.com>
Cc:     Theodore Ts'o <tytso@mit.edu>,
        Aleksandr Nogikh <nogikh@google.com>, adilger.kernel@dilger.ca,
        jack@suse.com, linux-ext4@vger.kernel.org,
        syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+af5e10f73dbff48f70af@syzkaller.appspotmail.com>
Subject: Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super
 (2)
Message-ID: <20230616154953.etu5cg3se3sucem6@quack3>
References: <00000000000079134b05fdf78048@google.com>
 <20230613180103.GC18303@mit.edu>
 <ZIudnDI5JZU+4w42@dread.disaster.area>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZIudnDI5JZU+4w42@dread.disaster.area>
Precedence: bulk

On Fri 16-06-23 09:24:12, Dave Chinner wrote:
> On Tue, Jun 13, 2023 at 02:01:03PM -0400, Theodore Ts'o wrote:
> > I wonder if we should have a separate syzkaller subsystem for ext2 (as
> > distinct from ext4)?  The syz reproducer seems to know that it should
> > be mounting using ext2, but also calls it an ext4 file system, which
> > is a bit weird.  I'm guessing there is something specific about the
> > syzkaller internals which might not make this be practical, but I
> > thought I should ask.
> > 
> > From the syz reproducer:
> > 
> > syz_mount_image$ext4(&(0x7f0000000100)='ext2\x00', ...)
> > 
> > More generally, there are a series of changes that were made to make
> > ext4 to make it more robust against maliciously fuzzed superblocks,
> > but we haven't necessarily made sure the same analogous changes have
> > been made to ext2.  I'm not sure how critical this is in practice,
> > since most distributions don't actually compile fs/ext2 and instead
> > use CONFIG_EXT4_USE_FOR_EXT2 instead.  However, while we maintain ext2
> > as a sample "simple" modern file system, I guess we should try to make
> > sure we do carry those fixes over.
> 
> Hmmmm.
> 
> Modern filesystems are crash resilient, based on extents and are
> using/moving to folios+iomap - calling a non-journalled, indirect
> block indexed, bufferhead based code base (that nobody is really
> using in production) "modern" seems like a real stretch.

Yeah, modern is a stretch. But I guess what Ted meant is that we try to
keep ext2 reasonably uptodate with various infrastructure changes. We have
now queued conversion of ext2 direct IO path to iomap and are looking into
converting buffered IO path to iomap as a sample to get experience for ext4
conversion and also conversion of other "simple" filesystems.

> I have my doubts that maintaining fs/ext2 is providing much benefit
> to anyone.  The code base is in the git history if anyone wants to
> study it, so it's not like we have to keep it active in the tree for
> it to remain a code base that people can learn from.
> 
> Therefore, given the current push to sideline/remove bufferheads
> from the kernel, should we simply deprecate fs/ext2 and then remove
> it in a year or two like we're doing with reiser to reduce our
> future maintenance and/or conversion burden?

That's a fair remark and if there is a general sentiment that ext2 codebase
is not really useful, I certainly won't mind having one less fs to
maintain. I'd just note that having ext2 in git history will not provide
very useful insight into how various current infrastructure changes could
be implemented for simple filesystems.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR