All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yongji Xie <xieyongji@bytedance.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	arve@android.com, tkjos@android.com, maco@android.com,
	joel@joelfernandes.org, hridya@google.com, surenb@google.com,
	viro@zeniv.linux.org.uk, sargun@sargun.me, keescook@chromium.org,
	Jason Wang <jasowang@redhat.com>,
	devel@driverdev.osuosl.org, linux-fsdevel@vger.kernel.org
Subject: Re: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
Date: Thu, 1 Apr 2021 19:11:27 +0800	[thread overview]
Message-ID: <CACycT3v3b7sfswm5Og9Pk-Q=FTD_RabTudv3TkHqo8fdSQvsXA@mail.gmail.com> (raw)
In-Reply-To: <20210401104034.52qaaoea27htkpbh@wittgenstein>

On Thu, Apr 1, 2021 at 6:40 PM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>
> On Thu, Apr 01, 2021 at 11:54:45AM +0200, Greg KH wrote:
> > On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote:
> > > Use receive_fd() to receive file from another process instead of
> > > combination of get_unused_fd_flags() and fd_install(). This simplifies
> > > the logic and also makes sure we don't miss any security stuff.
> >
> > But no logic is simplified here, and nothing is "missed", so I do not
> > understand this change at all.
> >
> > >
> > > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > > ---
> > >  drivers/android/binder.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > index c119736ca56a..080bcab7d632 100644
> > > --- a/drivers/android/binder.c
> > > +++ b/drivers/android/binder.c
> > > @@ -3728,7 +3728,7 @@ static int binder_apply_fd_fixups(struct binder_proc *proc,
> > >     int ret = 0;
> > >
> > >     list_for_each_entry(fixup, &t->fd_fixups, fixup_entry) {
> > > -           int fd = get_unused_fd_flags(O_CLOEXEC);
> > > +           int fd  = receive_fd(fixup->file, O_CLOEXEC);
> >
> > Why 2 spaces?
> >
> > >
> > >             if (fd < 0) {
> > >                     binder_debug(BINDER_DEBUG_TRANSACTION,
> > > @@ -3741,7 +3741,7 @@ static int binder_apply_fd_fixups(struct binder_proc *proc,
> > >                          "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);
> > > +           fput(fixup->file);
> >
> > Are you sure this is the same???
> >
> > I d onot understand the need for this change at all, what is wrong with
> > the existing code here?
>
> I suggested something like this.
> Some time back we added receive_fd() for seccomp and SCM_RIGHTS to have
> a unified way of installing file descriptors including taking care of
> handling sockets and running security hooks. The helper also encompasses
> the whole get_unused_fd() + fd_install dance.
> My suggestion was to look at all the places were we currently open-code
> this in drivers/:
>

Sorry for not following your suggestion. Yes, I looked at those
places. But I found that we will add security_file_receive()
implicitly if we replace get_unused_fd() + fd_install() with
receive_fd() for most drivers. Not sure if there will be some
regression. So I only do that where I think security_file_receive() is
needed, that is this patch. Although it looks like this is not a good
idea now...

Thanks,
Yongji

WARNING: multiple messages have this Message-ID (diff)
From: Yongji Xie <xieyongji@bytedance.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: devel@driverdev.osuosl.org, tkjos@android.com,
	keescook@chromium.org, Greg KH <gregkh@linuxfoundation.org>,
	Jason Wang <jasowang@redhat.com>,
	sargun@sargun.me, Christoph Hellwig <hch@infradead.org>,
	hridya@google.com, arve@android.com, viro@zeniv.linux.org.uk,
	joel@joelfernandes.org, linux-fsdevel@vger.kernel.org,
	maco@android.com, surenb@google.com
Subject: Re: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
Date: Thu, 1 Apr 2021 19:11:27 +0800	[thread overview]
Message-ID: <CACycT3v3b7sfswm5Og9Pk-Q=FTD_RabTudv3TkHqo8fdSQvsXA@mail.gmail.com> (raw)
In-Reply-To: <20210401104034.52qaaoea27htkpbh@wittgenstein>

On Thu, Apr 1, 2021 at 6:40 PM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>
> On Thu, Apr 01, 2021 at 11:54:45AM +0200, Greg KH wrote:
> > On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote:
> > > Use receive_fd() to receive file from another process instead of
> > > combination of get_unused_fd_flags() and fd_install(). This simplifies
> > > the logic and also makes sure we don't miss any security stuff.
> >
> > But no logic is simplified here, and nothing is "missed", so I do not
> > understand this change at all.
> >
> > >
> > > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > > ---
> > >  drivers/android/binder.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > index c119736ca56a..080bcab7d632 100644
> > > --- a/drivers/android/binder.c
> > > +++ b/drivers/android/binder.c
> > > @@ -3728,7 +3728,7 @@ static int binder_apply_fd_fixups(struct binder_proc *proc,
> > >     int ret = 0;
> > >
> > >     list_for_each_entry(fixup, &t->fd_fixups, fixup_entry) {
> > > -           int fd = get_unused_fd_flags(O_CLOEXEC);
> > > +           int fd  = receive_fd(fixup->file, O_CLOEXEC);
> >
> > Why 2 spaces?
> >
> > >
> > >             if (fd < 0) {
> > >                     binder_debug(BINDER_DEBUG_TRANSACTION,
> > > @@ -3741,7 +3741,7 @@ static int binder_apply_fd_fixups(struct binder_proc *proc,
> > >                          "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);
> > > +           fput(fixup->file);
> >
> > Are you sure this is the same???
> >
> > I d onot understand the need for this change at all, what is wrong with
> > the existing code here?
>
> I suggested something like this.
> Some time back we added receive_fd() for seccomp and SCM_RIGHTS to have
> a unified way of installing file descriptors including taking care of
> handling sockets and running security hooks. The helper also encompasses
> the whole get_unused_fd() + fd_install dance.
> My suggestion was to look at all the places were we currently open-code
> this in drivers/:
>

Sorry for not following your suggestion. Yes, I looked at those
places. But I found that we will add security_file_receive()
implicitly if we replace get_unused_fd() + fd_install() with
receive_fd() for most drivers. Not sure if there will be some
regression. So I only do that where I think security_file_receive() is
needed, that is this patch. Although it looks like this is not a good
idea now...

Thanks,
Yongji
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2021-04-01 11:12 UTC|newest]

Thread overview: 58+ 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 ` Xie Yongji
2021-04-01  9:09 ` [PATCH 1/2] file: Export receive_fd() to modules Xie Yongji
2021-04-01  9:09   ` Xie Yongji
2021-04-01  9:52   ` Greg KH
2021-04-01  9:52     ` Greg KH
2021-04-01 10:24     ` Yongji Xie
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:09   ` Xie Yongji
2021-04-01  9:54   ` Greg KH
2021-04-01  9:54     ` Greg KH
2021-04-01 10:12     ` Yongji Xie
2021-04-01 10:12       ` Yongji Xie
2021-04-01 10:42       ` Greg KH
2021-04-01 10:42         ` Greg KH
2021-04-01 11:29         ` Yongji Xie
2021-04-01 11:29           ` Yongji Xie
2021-04-01 11:33           ` Greg KH
2021-04-01 11:33             ` Greg KH
2021-04-01 12:28             ` Yongji Xie
2021-04-01 12:28               ` Yongji Xie
2021-04-01 14:09               ` Greg KH
2021-04-01 14:09                 ` Greg KH
2021-04-02  9:12                 ` Kees Cook
2021-04-02  9:12                   ` Kees Cook
2021-04-01 10:40     ` Christian Brauner
2021-04-01 10:40       ` Christian Brauner
2021-04-01 11:11       ` Yongji Xie [this message]
2021-04-01 11:11         ` Yongji Xie
2021-04-16  5:19       ` Al Viro
2021-04-16  5:19         ` Al Viro
2021-04-16  5:55         ` Al Viro
2021-04-16  5:55           ` Al Viro
2021-04-16 13:42           ` Christian Brauner
2021-04-16 13:42             ` Christian Brauner
2021-04-16 14:09             ` Al Viro
2021-04-16 14:09               ` Al Viro
2021-04-16 15:13               ` Christian Brauner
2021-04-16 15:13                 ` Christian Brauner
2021-04-16 15:35                 ` Al Viro
2021-04-16 15:35                   ` Al Viro
2021-04-16 15:58                   ` Christian Brauner
2021-04-16 15:58                     ` Christian Brauner
2021-04-16 16:00                     ` Christian Brauner
2021-04-16 16:00                       ` Christian Brauner
2021-04-16 17:00                       ` Al Viro
2021-04-16 17:00                         ` Al Viro
2021-04-16 17:30                     ` Al Viro
2021-04-16 17:30                       ` Al Viro
2021-04-17  1: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  9:53   ` Greg KH
2021-04-01 10:00   ` Yongji Xie
2021-04-01 10:00     ` Yongji Xie
2021-04-01 10:20 ` Christian Brauner
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='CACycT3v3b7sfswm5Og9Pk-Q=FTD_RabTudv3TkHqo8fdSQvsXA@mail.gmail.com' \
    --to=xieyongji@bytedance.com \
    --cc=arve@android.com \
    --cc=christian.brauner@ubuntu.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 \
    /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.