All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>
Cc: David Laight <David.Laight@aculab.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>,
	Iurii Zaikin <yzaikin@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 03/11] fs: add new read_uptr and write_uptr file operations
Date: Wed, 8 Jul 2020 05:14:55 +0000	[thread overview]
Message-ID: <20200708051455.GA4332@42.do-not-panic.com> (raw)
In-Reply-To: <CAHk-=wjxQczqZ96esvDrH5QZsLg6azXCGDgo+Bmm6r8t2ssasg@mail.gmail.com>

On Sat, Jun 27, 2020 at 09:33:03AM -0700, Linus Torvalds wrote:
> The real problem with
> "set_fs()" has been that we've occasionally had bugs where we ended up
> running odd paths that we really didn't _intend_ to run with kernel
> pointers. The classic example is the SCSI "write as ioctl" example,
> where a write to a SCSI generic device would do various odd things and
> follow pointers and what-not. Then you get into real trouble when
> "splice()" ends up truiong to write a kernel buffer, and because of
> "set_fs()" suddenly the sg code started accessing kernel memory
> willy-nilly.

So the semantics of this interface can create chaos fast if not used
carefully and conservatively.

Christoph, it would be great if you're future series can include some
version of a verbiage for the motivation for the culling of set_fs().
Maybe it was just me, but the original motivation wasn't clear at first
and took some thread digging to get it.

  Luis

  parent reply	other threads:[~2020-07-08  5:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 16:28 [RFC] stop using ->read and ->write for kernel access Christoph Hellwig
2020-06-24 16:28 ` [PATCH 01/11] uptr: add a new "universal pointer" type Christoph Hellwig
2020-06-24 16:28 ` [PATCH 02/11] fs: factor out a set_fmode_can_read_write helper Christoph Hellwig
2020-06-24 16:28 ` [PATCH 03/11] fs: add new read_uptr and write_uptr file operations Christoph Hellwig
2020-06-24 17:19   ` Linus Torvalds
2020-06-24 17:55     ` Christoph Hellwig
2020-06-24 18:11       ` Linus Torvalds
2020-06-24 18:14         ` Christoph Hellwig
2020-06-24 18:20           ` Linus Torvalds
2020-06-24 18:24             ` Christoph Hellwig
2020-06-24 18:29               ` Matthew Wilcox
2020-06-24 18:31                 ` Christoph Hellwig
2020-06-24 18:15         ` Linus Torvalds
2020-06-27 10:49         ` David Laight
2020-06-27 16:33           ` Linus Torvalds
2020-06-29  8:21             ` David Laight
2020-06-29 15:29             ` Christoph Hellwig
2020-06-29 17:02               ` Linus Torvalds
2020-06-29 18:07                 ` Christoph Hellwig
2020-06-29 18:29                   ` Linus Torvalds
2020-06-29 18:36                     ` Christoph Hellwig
2020-06-29 19:10                       ` Linus Torvalds
2020-06-30  7:04                         ` Christoph Hellwig
2020-06-30  7:51                 ` David Laight
2020-07-08  5:14             ` Luis Chamberlain [this message]
2020-06-24 17:56     ` Matthew Wilcox
2020-06-24 17:59       ` Christoph Hellwig
2020-06-24 18:37         ` Christoph Hellwig
2020-06-24 18:43           ` Matthew Wilcox
2020-06-24 16:28 ` [PATCH 04/11] sysctl: switch to ->{read,write}_uptr Christoph Hellwig
2020-06-24 16:28 ` [PATCH 05/11] fs: refactor new_sync_read Christoph Hellwig
2020-06-24 16:28 ` [PATCH 06/11] proc: add a read_iter method to proc proc_ops Christoph Hellwig
2020-06-24 16:28 ` [PATCH 07/11] seq_file: add seq_read_iter Christoph Hellwig
2020-06-24 16:28 ` [PATCH 08/11] seq_file: switch over direct seq_read method calls to seq_read_iter Christoph Hellwig
2020-06-24 16:28 ` [PATCH 09/11] proc: " Christoph Hellwig
2020-06-24 16:29 ` [PATCH 10/11] fs: don't allow kernel reads and writes using ->read and ->write Christoph Hellwig
2020-06-24 16:29 ` [PATCH 11/11] fs: don't allow splice read/write without explicit ops Christoph Hellwig

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=20200708051455.GA4332@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=David.Laight@aculab.com \
    --cc=hch@lst.de \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yzaikin@google.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.