Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	linux-arm-kernel@lists.infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
	io-uring@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-mm@kvack.org, netdev@vger.kernel.org,
	keyrings@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
Date: Sun, 20 Sep 2020 19:07:42 +0100
Message-ID: <20200920180742.GN3421308@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200920151510.GS32101@casper.infradead.org>

On Sun, Sep 20, 2020 at 04:15:10PM +0100, Matthew Wilcox wrote:
> On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote:
> > Add a flag to force processing a syscall as a compat syscall.  This is
> > required so that in_compat_syscall() works for I/O submitted by io_uring
> > helper threads on behalf of compat syscalls.
> 
> Al doesn't like this much, but my suggestion is to introduce two new
> opcodes -- IORING_OP_READV32 and IORING_OP_WRITEV32.  The compat code
> can translate IORING_OP_READV to IORING_OP_READV32 and then the core
> code can know what that user pointer is pointing to.

Let's separate two issues:
	1) compat syscalls want 32bit iovecs.  Nothing to do with the
drivers, dealt with just fine.
	2) a few drivers are really fucked in head.  They use different
*DATA* layouts for reads/writes, depending upon the calling process.
IOW, if you fork/exec a 32bit binary and your stdin is one of those,
reads from stdin in parent and child will yield different data layouts.
On the same struct file.
	That's what Christoph worries about (/dev/sg he'd mentioned is
one of those).

	IMO we should simply have that dozen or so of pathological files
marked with FMODE_SHITTY_ABI; it's not about how they'd been opened -
it describes the userland ABI provided by those.  And it's cast in stone.

	Any in_compat_syscall() in ->read()/->write() instances is an ABI
bug, plain and simple.  Some are unfixable for compatibility reasons, but
any new caller like that should be a big red flag.

	How we import iovec array is none of the drivers' concern; we do
not need to mess with in_compat_syscall() reporting the matching value,
etc. for that.  It's about the instances that want in_compat_syscall() to
decide between the 32bit and 64bit data layouts.  And I believe that
we should simply have them marked as such and rejected by io_uring.  With
any new occurences getting slapped down hard.

	Current list of those turds:
/dev/sg (pointer-chasing, generally insane)
/sys/firmware/efi/vars/*/raw_var (fucked binary structure)
/sys/firmware/efi/vars/new_var (fucked binary structure)
/sys/firmware/efi/vars/del_var (fucked binary structure)
/dev/uhid	(pointer-chasing for one obsolete command)
/dev/input/event* (timestamps)
/dev/uinput (timestamps)
/proc/bus/input/devices (fucked bitmap-to-text representation)
/sys/class/input/*/capabilities/* (fucked bitmap-to-text representation)

  parent reply index

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 12:45 let import_iovec deal with compat_iovecs as well Christoph Hellwig
2020-09-18 12:45 ` [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag Christoph Hellwig
2020-09-18 13:40   ` Al Viro
2020-09-18 13:44     ` Christoph Hellwig
2020-09-18 13:58       ` Al Viro
2020-09-18 15:16         ` Christoph Hellwig
2020-09-19 16:21           ` Andy Lutomirski
2020-09-19 21:16             ` Arnd Bergmann
2020-09-19 21:52               ` Finn Thain
2020-09-19 22:22               ` Andy Lutomirski
2020-09-21 16:10                 ` Pavel Begunkov
2020-09-21 16:13                   ` Pavel Begunkov
2020-09-21 23:51                     ` Andy Lutomirski
2020-09-22  0:22                       ` Pavel Begunkov
2020-09-22  0:58                         ` Andy Lutomirski
2020-09-22  6:30                           ` Pavel Begunkov
2020-09-22  7:23                             ` Arnd Bergmann
2020-09-22  7:57                               ` Pavel Begunkov
2020-09-22  9:01                                 ` Arnd Bergmann
2020-09-22 16:20                                   ` Andy Lutomirski
2020-09-23  8:01                                   ` Pavel Begunkov
2020-09-23 13:22                                     ` Al Viro
2020-09-19 22:09           ` Al Viro
2020-09-19 22:23             ` Andy Lutomirski
2020-09-19 22:41               ` Al Viro
2020-09-19 22:53                 ` Andy Lutomirski
2020-09-19 23:24                   ` Al Viro
2020-09-20  0:14                     ` Andy Lutomirski
2020-09-20  2:57                       ` Al Viro
2020-09-20 16:59                         ` Andy Lutomirski
2020-09-20 18:12                           ` Al Viro
2020-09-20 13:55             ` Arnd Bergmann
2020-09-20 15:02               ` Al Viro
2020-09-19 14:53         ` David Laight
2020-09-18 13:59       ` Arnd Bergmann
2020-09-20 15:15   ` Matthew Wilcox
2020-09-20 15:55     ` William Kucharski
2020-09-21 16:20       ` Pavel Begunkov
2020-09-20 16:00     ` Arnd Bergmann
2020-09-20 18:07     ` Al Viro [this message]
2020-09-20 18:41       ` Al Viro
2020-09-20 19:01       ` Matthew Wilcox
2020-09-20 19:10         ` Al Viro
2020-09-20 19:22           ` Matthew Wilcox
2020-09-20 19:28             ` Andy Lutomirski
2020-09-20 20:49               ` Arnd Bergmann
2020-09-20 21:13                 ` David Laight
2020-09-21 16:31                   ` Pavel Begunkov
2020-09-20 21:42             ` Al Viro
2020-09-21 16:26             ` Pavel Begunkov
2020-09-20 19:14       ` Andy Lutomirski
2020-09-21  4:28         ` Christoph Hellwig
2020-09-18 12:45 ` [PATCH 2/9] compat.h: fix a spelling error in <linux/compat.h> Christoph Hellwig
2020-09-18 13:37   ` Johannes Thumshirn
2020-09-18 12:45 ` [PATCH 3/9] fs: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector Christoph Hellwig
2020-09-18 12:56   ` Matthew Wilcox
2020-09-18 13:39   ` Johannes Thumshirn
2020-09-18 12:45 ` [PATCH 4/9] fs: handle the compat case in import_iovec Christoph Hellwig
2020-09-18 12:45 ` [PATCH 5/9] fs: remove various compat readv/writev helpers Christoph Hellwig
2020-09-18 12:45 ` [PATCH 6/9] fs: remove the compat readv/writev syscalls Christoph Hellwig
2020-09-18 12:45 ` [PATCH 7/9] fs: remove compat_sys_vmsplice Christoph Hellwig
2020-09-18 12:45 ` [PATCH 8/9] mm: remove compat_process_vm_{readv,writev} Christoph Hellwig
2020-09-18 13:48   ` Arnd Bergmann
2020-09-18 12:45 ` [PATCH 9/9] security/keys: remove compat_keyctl_instantiate_key_iov Christoph Hellwig
2020-09-19 14:24 ` let import_iovec deal with compat_iovecs as well David Laight
2020-09-21  4:41   ` 'Christoph Hellwig'
2020-09-21 11:11     ` David Laight

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=20200920180742.GN3421308@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=dhowells@redhat.com \
    --cc=hch@lst.de \
    --cc=io-uring@vger.kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git