linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>, Jan Kara <jack@suse.cz>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	yebin <yebin@huaweicloud.com>,
	linux-fsdevel@vger.kernel.org, Kees Cook <keescook@google.com>,
	Alexander Popov <alex.popov@linux.com>,
	syzkaller <syzkaller@googlegroups.com>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH] block: Add config option to not allow writing to mounted devices
Date: Tue, 13 Jun 2023 22:57:07 -0400	[thread overview]
Message-ID: <20230614025707.GA48153@mit.edu> (raw)
In-Reply-To: <20230614020412.GB11423@frogsfrogsfrogs>

On Tue, Jun 13, 2023 at 07:04:12PM -0700, Darrick J. Wong wrote:
> 
> Well in that case, post a patchset adding "depends on INSECURE" for
> every subsystem that syzbot files bugs against, if the maintainers do
> not immediately drop what they're doing to resolve the bug.
> 
> Google extracts a bunch more unpaid labor from society to make its
> owners richer, and everyone else on the planet suffers for it, just like
> you all have done for the past 25 years.  That's the definition of
> Googley!!

To be fair, I don't think this is the official position of Google, but
rather Dmitry's personal security ideology (as Dave put it).

Dmitry, tell you what.  If you can find a vice president inside Google
who thinks this that preventing an attacker who has the ability to
modify a block device while it is mounted, while running code under
the control of the attacker, from being to potentially trigger the
ability to run ring 0 code --- and who believes it enough to actually
**fund** a headcount to actually work these syzbot reports --- I'll
gladly help to supervise that person and mentor their ability to work
these ext4 syzbot reports.

But I think you will find that the VP's will believe that this is not
a threat that has a genuine business case which is important enough
that they are willing to fund it.  And I'm saying as an upstream
developer, *other* syzbot reports are higher priority, because in my
judgement, they are much more willing to impact real users, and are
more likely to be issues that management chain would consider higher
priority.  (Never mind that *all* of my syzbot work has been done on
my own time.)

For those of us who are working with limited resources, and doing this
work out of the kindness of our hearts, it would be nice to filter out
those syzbot reports that in our best judgement, constitute **noise**.
If there is not a good way to filter out the noise, it is likely that
upstream developers will choose to use their time working with other
tools that are better suited to getting our job done as we understand
it.

So far, there is been a lot work done by folks on your team which has
made syzbot easier for us to use, and for that, I thank you.  But your
position on forcing your ideology of which security bugs I should fix
on my own time is.... annoying.  And if others feel the same way, your
attitude is going to be counter-productive towards the goals you have
towards making Linux more secure.

Sometimes, the "best" is the enemy is the "good enough".  And in this
era of Google's "sharpened focus" or Facebook's "year of efficiency",
very often, "good enough" is all the vice presidents are willing to
fund.

Best regards,

						- Ted

  reply	other threads:[~2023-06-14  2:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 16:16 [PATCH] block: Add config option to not allow writing to mounted devices Jan Kara
2023-06-12 16:25 ` Jan Kara
2023-06-12 17:39   ` Bart Van Assche
2023-06-12 17:47     ` Theodore Ts'o
2023-06-12 18:52     ` Colin Walters
2023-06-13 11:34       ` Jan Kara
2023-06-14  1:55         ` Darrick J. Wong
2023-06-14  7:14           ` Christoph Hellwig
2023-06-14  7:05         ` Christian Brauner
2023-06-14  7:07           ` Christoph Hellwig
2023-06-14  7:10         ` Christoph Hellwig
2023-06-14 10:12           ` Jan Kara
2023-06-14 14:30             ` Christoph Hellwig
2023-06-14 14:46             ` Matthew Wilcox
2023-06-13  4:56 ` kernel test robot
2023-06-13  5:10 ` Christoph Hellwig
2023-06-13  6:09   ` Dmitry Vyukov
2023-06-14  7:17     ` Christoph Hellwig
2023-06-14  8:18       ` Christian Brauner
2023-06-14 10:36         ` Jan Kara
2023-06-14 12:48           ` Christian Brauner
2023-06-15 14:39             ` Jan Kara
2023-06-14 14:31         ` Christoph Hellwig
2023-06-13 20:56   ` Jan Kara
2023-06-14  7:20     ` Christoph Hellwig
2023-06-20 10:41       ` Jan Kara
2023-06-20 11:29         ` Christoph Hellwig
2023-06-14  7:35     ` Christian Brauner
2023-06-13  6:49 ` Dmitry Vyukov
2023-06-13 19:22   ` Theodore Ts'o
2023-06-14  0:26   ` Dave Chinner
2023-06-14  2:04   ` Darrick J. Wong
2023-06-14  2:57     ` Theodore Ts'o [this message]
2023-06-14 12:27     ` Dmitry Vyukov
2023-06-14 23:38       ` Dave Chinner
2023-06-15  9:14         ` Dmitry Vyukov
2023-06-18 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=20230614025707.GA48153@mit.edu \
    --to=tytso@mit.edu \
    --cc=alex.popov@linux.com \
    --cc=axboe@kernel.dk \
    --cc=djwong@kernel.org \
    --cc=dvyukov@google.com \
    --cc=ebiggers@google.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=keescook@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=yebin@huaweicloud.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).