linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Xie Yongji <xieyongji@bytedance.com>,
	hch@infradead.org, arve@android.com, tkjos@android.com,
	maco@android.com, joel@joelfernandes.org, hridya@google.com,
	surenb@google.com, sargun@sargun.me, keescook@chromium.org,
	jasowang@redhat.com, devel@driverdev.osuosl.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
Date: Fri, 16 Apr 2021 17:58:15 +0200	[thread overview]
Message-ID: <20210416155815.ayjpnx37dv3a4jos@wittgenstein> (raw)
In-Reply-To: <YHmu3/Cw4bUnTSH9@zeniv-ca.linux.org.uk>

On Fri, Apr 16, 2021 at 03:35:59PM +0000, Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote:
> 
> > My point here was more that the _file_ has already been opened _before_
> > that call to io_uring_add_task_file(). But any potential non-trivial
> > side-effects of opening that file that you correctly pointed out in an
> > earlier mail has already happened by that time.
> 
> The file comes from io_uring_get_file(), the entire thing is within the
> io_ring_ctx constructor and the only side effect there is ->ring_sock
> creation.  And that stays until the io_ring_ctx is freed.  I'm _not_
> saying I like io_uring style in general, BTW - in particular,
> ->ring_sock->file handling is a kludge (as is too much of interation
> with AF_UNIX machinery there).  But from side effects POV we are fine
> there.
> 
> > Granted there are more
> > obvious examples, e.g. the binder stuff.
> > 
> > 		int fd = get_unused_fd_flags(O_CLOEXEC);
> > 
> > 		if (fd < 0) {
> > 			binder_debug(BINDER_DEBUG_TRANSACTION,
> > 				     "failed fd fixup txn %d fd %d\n",
> > 				     t->debug_id, fd);
> > 			ret = -ENOMEM;
> > 			break;
> > 		}
> > 		binder_debug(BINDER_DEBUG_TRANSACTION,
> > 			     "fd fixup txn %d fd %d\n",
> > 			     t->debug_id, fd);
> > 		trace_binder_transaction_fd_recv(t, fd, fixup->offset);
> > 		fd_install(fd, fixup->file);
> > 		fixup->file = NULL;
> > 		if (binder_alloc_copy_to_buffer(&proc->alloc, t->buffer,
> > 						fixup->offset, &fd,
> > 						sizeof(u32))) {
> > 			ret = -EINVAL;
> > 			break;
> > 		}
> 
> ... and it's actually broken, since this
>         /* All copies must be 32-bit aligned and 32-bit size */
> 	if (!check_buffer(alloc, buffer, buffer_offset, bytes))
> 		return -EINVAL;
> in binder_alloc_copy_to_buffer() should've been done *before*
> fd_install().  If anything, it's an example of the situation when
> fd_receive() would be wrong...

They could probably refactor this but I'm not sure why they'd bother. If
they fail processing any of those files they end up aborting the
whole transaction.
(And the original code didn't check the error code btw.)

  reply	other threads:[~2021-04-16 15:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  9:09 [PATCH 0/2] Export receive_fd() to modules and do some cleanups Xie Yongji
2021-04-01  9:09 ` [PATCH 1/2] file: Export receive_fd() to modules Xie Yongji
2021-04-01  9:52   ` Greg KH
2021-04-01 10:24     ` Yongji Xie
2021-04-01  9:09 ` [PATCH 2/2] binder: Use receive_fd() to receive file from another process Xie Yongji
2021-04-01  9:54   ` Greg KH
2021-04-01 10:12     ` Yongji Xie
2021-04-01 10:42       ` Greg KH
2021-04-01 11:29         ` Yongji Xie
2021-04-01 11:33           ` Greg KH
2021-04-01 12:28             ` Yongji Xie
2021-04-01 14:09               ` Greg KH
2021-04-02  9:12                 ` Kees Cook
2021-04-01 10:40     ` Christian Brauner
2021-04-01 11:11       ` Yongji Xie
2021-04-16  5:19       ` Al Viro
2021-04-16  5:55         ` Al Viro
2021-04-16 13:42           ` Christian Brauner
2021-04-16 14:09             ` Al Viro
2021-04-16 15:13               ` Christian Brauner
2021-04-16 15:35                 ` Al Viro
2021-04-16 15:58                   ` Christian Brauner [this message]
2021-04-16 16:00                     ` Christian Brauner
2021-04-16 17:00                       ` Al Viro
2021-04-16 17:30                     ` Al Viro
2021-04-17  1:30                       ` Al Viro
2021-04-01  9:53 ` [PATCH 0/2] Export receive_fd() to modules and do some cleanups Greg KH
2021-04-01 10:00   ` Yongji Xie
2021-04-01 10:20 ` Christian Brauner

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=20210416155815.ayjpnx37dv3a4jos@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=arve@android.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=hridya@google.com \
    --cc=jasowang@redhat.com \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=sargun@sargun.me \
    --cc=surenb@google.com \
    --cc=tkjos@android.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xieyongji@bytedance.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).