[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <X/ypZFpMMCnHZtd4@sol.localdomain>
Date: Mon, 11 Jan 2021 11:39:16 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Pavel Machek <pavel@....cz>, "Theodore Y. Ts'o" <tytso@....edu>,
Josh Triplett <josh@...htriplett.org>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-ext4@...r.kernel.org
Subject: Re: Malicious fs images was Re: ext4 regression in v5.9-rc2 from
e7bfb5c9bb3d on ro fs with overlapped bitmaps
On Mon, Jan 11, 2021 at 10:51:20AM -0800, Darrick J. Wong wrote:
> On Sun, Jan 10, 2021 at 07:41:02PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > On Fri 2020-10-09 10:37:32, Theodore Y. Ts'o wrote:
> > > On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
> > > >
> > > > I wasn't trying to make a *new* general principle or policy. I was under
> > > > the impression that this *was* the policy, because it never occurred to
> > > > me that it could be otherwise. It seemed like a natural aspect of the
> > > > kernel/userspace boundary, to the point that the idea of it *not* being
> > > > part of the kernel's stability guarantees didn't cross my mind.
> > >
> > > >From our perspective (and Darrick and I discussed this on this week's
> > > ext4 video conference, so it represents the ext4 and xfs maintainer's
> > > position) is that the file system format is different. First, the
> > > on-disk format is not an ABI, and it is several orders more complex
> > > than a system call interface. Second, we make no guarantees about
> > > what the file system created by malicious tools will do. For example,
> > > XFS developers reject bug reports from file system fuzzers, because
>
> My recollection of this is quite different -- sybot was sending multiple
> zeroday exploits per week to the public xfs list, and nobody at Google
> was helping us to /fix/ those bugs.Each report took hours of developer
> time to extract the malicious image (because Dmitry couldn't figure out
> how to add that ability to syzbot) and syscall sequence from the
> reproducer program, plus whatever time it took to craft a patch, test
> it, and push it through review.
>
> Dave and I complained to Dmitry about how the community had zero input
> into the rate at which syzbot was allowed to look for xfs bugs. Nobody
> at Google would commit to helping fix any of the XFS bugs, and Dmitry
> would not give us better choices than (a) Google AI continuing to create
> zerodays and leaving the community to clean up the mess, or (b) shutting
> off syzbot entirely. At the time I said I would accept letting syzbot
> run against xfs until it finds something, and turning it off until we
> resolve the issue. That wasn't acceptable, because (I guess) nobody at
> Google wants to put /any/ staff time into XFS at all.
>
> TLDR: XFS /does/ accept bug reports about fuzzed and broken images.
> What we don't want is make-work Google AIs spraying zeroday code in
> public places and the community developers having to clean up the mess.
syzkaller is an open source project that implements a coverage-guided fuzzer for
multiple operating system kernels; it's not "Google AI".
Anyone can run syzkaller (either by itself, or as part of a syzbot instance) and
find the same bugs.
- Eric
Powered by blists - more mailing lists