All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eric Biggers <ebiggers3@gmail.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Brian Foster <bfoster@redhat.com>,
	syzbot <syzbot+568245b88fbaedcb1959@syzkaller.appspotmail.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: INFO: task hung in xlog_grant_head_check
Date: Wed, 23 May 2018 13:01:59 -0500	[thread overview]
Message-ID: <a52266f9-0096-b28c-c01c-046ababcfe3a@sandeen.net> (raw)
In-Reply-To: <20180523162015.GA3684@sol.localdomain>

On 5/23/18 11:20 AM, Eric Biggers wrote:
> Hi Darrick,

...

> Now, if you *really* don't want syzbot to report XFS bugs as you believe XFS
> contains known unfixable bugs or for other reasons, you can formally ask Dmitry
> to remove CONFIG_XFS_FS from the syzbot config.  But of course that doesn't make
> the bugs go away, it just makes the bug reports go away; you'll have to fix them
> eventually anyway, one way or another.

I'd revise that to "have to fix /some/ of them anyway."

What I'm personally hung up on are the bugs where the "exploit" involves merely
mounting a crafted filesystem that in reality would never (until the heat death
of the universe) corrupt itself into that state on its own; it's the "malicious
image" case, which is quite different than exposing fundamental bugs like the
SB_BORN race or or the user-exploitable ext4 flaw you mentioned in your reply.
Those are more insidious and/or things which can be hit by real users in real life.

I don't know if I can win the "malicious images aren't a critical security
threat" battle, but I do think they are at least a different class of flaws,
because as Dave said, mount is supposed to be a privileged operation.
In a perfect world we'd fix them anyway, but I don't know that our resource
pool can keep up with your google-scale bot and still make progress in other
critical areas.

Anyway, the upshot is that we're probably just not going to care much about V4
filesystem oops-or-hang-on-mount bugs.  Those problems are solved (largely) with
V5 filesystem format.  Maybe I /will/ propose a system-wide tunable to disallow
V4 for those who are worried about such things.

To Darrick's points about more collaboration, I still wish that our requests
for more traditional fs fuzzer reporting (i.e. a filesystem image) weren't met
with such resistance.Tailoring your bug reports to the needs of the developer
community you're interacting with seems like a pretty reasonable thing to do.

As an aside, I wonder how much coverage of the V5 format code syzkaller /has/
achieved; that would be another useful datapoint google could provide - if
syzkaller is in fact traversing the V5 codepaths and isn't turning anything
up, that'd be pretty useful to know.

Thanks,
-Eric

  reply	other threads:[~2018-05-23 18:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 17:55 INFO: task hung in xlog_grant_head_check syzbot
2018-05-22 12:31 ` Brian Foster
2018-05-22 22:26   ` Dave Chinner
2018-05-22 22:52     ` Eric Biggers
2018-05-23  4:47       ` Dave Chinner
2018-05-23  7:44       ` Darrick J. Wong
2018-05-23 16:20         ` Eric Biggers
2018-05-23 18:01           ` Eric Sandeen [this message]
2018-05-23 23:41             ` Bugs involving maliciously crafted file system Theodore Y. Ts'o
2018-05-24  0:49               ` Dave Chinner
2018-05-24  0:59                 ` Theodore Y. Ts'o
2018-05-24  3:55                   ` Dave Chinner
2018-05-24 13:16                   ` Eric Sandeen
2018-05-30 19:41                   ` Eric W. Biederman
2018-05-30 20:51                 ` Matthew Garrett
2018-06-11 13:11                   ` Dmitry Vyukov
2018-05-26 17:12               ` Dmitry Vyukov
2018-05-26 20:24                 ` Theodore Y. Ts'o
2018-06-11 13:07                   ` Dmitry Vyukov
2018-06-11 13:33                     ` Theodore Y. Ts'o
2018-06-15  9:32                       ` Dmitry Vyukov
2018-06-11 13:20             ` INFO: task hung in xlog_grant_head_check Dmitry Vyukov
2018-06-11 14:35               ` Eric Sandeen
2018-05-23 23:35           ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a52266f9-0096-b28c-c01c-046ababcfe3a@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=ebiggers3@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=syzbot+568245b88fbaedcb1959@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.