Thread (34 messages) 34 messages, 8 authors, 2021-01-13

Re: Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

From: Eric Biggers <ebiggers@kernel.org>
Date: 2021-01-11 19:40:15
Also in: lkml

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:
quoted
Hi!

On Fri 2020-10-09 10:37:32, Theodore Y. Ts'o wrote:
quoted
On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
quoted
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. 
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help