From: Christian Brauner <christian.brauner@ubuntu.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: "Christian Brauner" <christian@brauner.io>, "Hridya Valsaraju" <hridya@google.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Arve Hjønnevåg" <arve@android.com>, "Todd Kjos" <tkjos@android.com>, "Martijn Coenen" <maco@android.com>, "Joel Fernandes" <joel@joelfernandes.org>, "open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>, LKML <linux-kernel@vger.kernel.org>, syzkaller <syzkaller@googlegroups.com> Subject: Re: binderfs interferes with syzkaller? Date: Sun, 26 Jan 2020 10:51:33 +0100 [thread overview] Message-ID: <20200126095132.bq33azq7paqvedzx@wittgenstein> (raw) In-Reply-To: <CACT4Y+bckC4k-EpWiCkD+BBo5ypmkcb2g8Axb62LnBbwJjcqdw@mail.gmail.com> On Sat, Jan 25, 2020 at 07:13:03PM +0100, Dmitry Vyukov wrote: > On Sat, Jan 25, 2020 at 6:49 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > Hi binder maintainers, > > > > It seems that something has happened and now syzbot has 0 coverage in > > drivers/android/binder.c: > > https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html > > It covered at least something there before as it found some bugs in binder code. > > I _suspect_ it may be related to introduction binderfs, but it's > > purely based on the fact that binderfs changed lots of things there. > > And I see it claims to be backward compatible. > > > > syzkaller strategy to reach binder devices is to use > > CONFIG_ANDROID_BINDER_DEVICES to create a bunch of binderN devices (to > > give each test process a private one): > > https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config#L5671 > > > > Then it knows how to open these /dev/binderN devices: > > https://github.com/google/syzkaller/blob/master/sys/linux/dev_binder.txt#L22 > > and do stuff with them. > > > > Did these devices disappear or something? > > Oh, I see, it's backwards compatible if it's not enabled, right? It's backwards compatible. Let me give a little more detail. The legacy binder interface would create all devices listed in the module parameter CONFIG_ANDROID_BINDER_DEVICES. These devices were created using misc_register(&binder_device->miscdev); in the host's devtmpfs mount. If binderfs is enabled these devices are now created in the binderfs instance instead. For full backwards compatibility with old Android versions symlinks (or bind mounts) can be provided in the host's devtmpfs. This is what I recommended a few months ago. > And we enabled it because, well, enabling things generally gives more > coverage. I guess I will disable CONFIG_ANDROID_BINDERFS for now to I would at least try to test both somehow. It's likely that binderfs will replace legacy binder devices so if we could keep testing it somehow that would be great. > restore coverage in the binder itself. I'm not completely sure what you mean here. The binder IPC codepaths are nearly the same. The difference is mostly in how the device information is cast out before actual binder-ipc operations take place. In any case, testing both would obviously be preferred but binderfs strikes me as more worthy of testing. Christian
WARNING: multiple messages have this Message-ID (diff)
From: Christian Brauner <christian.brauner@ubuntu.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: "open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>, "Todd Kjos" <tkjos@android.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, "Joel Fernandes" <joel@joelfernandes.org>, "Arve Hjønnevåg" <arve@android.com>, syzkaller <syzkaller@googlegroups.com>, "Hridya Valsaraju" <hridya@google.com>, "Martijn Coenen" <maco@android.com>, "Christian Brauner" <christian@brauner.io> Subject: Re: binderfs interferes with syzkaller? Date: Sun, 26 Jan 2020 10:51:33 +0100 [thread overview] Message-ID: <20200126095132.bq33azq7paqvedzx@wittgenstein> (raw) In-Reply-To: <CACT4Y+bckC4k-EpWiCkD+BBo5ypmkcb2g8Axb62LnBbwJjcqdw@mail.gmail.com> On Sat, Jan 25, 2020 at 07:13:03PM +0100, Dmitry Vyukov wrote: > On Sat, Jan 25, 2020 at 6:49 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > Hi binder maintainers, > > > > It seems that something has happened and now syzbot has 0 coverage in > > drivers/android/binder.c: > > https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html > > It covered at least something there before as it found some bugs in binder code. > > I _suspect_ it may be related to introduction binderfs, but it's > > purely based on the fact that binderfs changed lots of things there. > > And I see it claims to be backward compatible. > > > > syzkaller strategy to reach binder devices is to use > > CONFIG_ANDROID_BINDER_DEVICES to create a bunch of binderN devices (to > > give each test process a private one): > > https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config#L5671 > > > > Then it knows how to open these /dev/binderN devices: > > https://github.com/google/syzkaller/blob/master/sys/linux/dev_binder.txt#L22 > > and do stuff with them. > > > > Did these devices disappear or something? > > Oh, I see, it's backwards compatible if it's not enabled, right? It's backwards compatible. Let me give a little more detail. The legacy binder interface would create all devices listed in the module parameter CONFIG_ANDROID_BINDER_DEVICES. These devices were created using misc_register(&binder_device->miscdev); in the host's devtmpfs mount. If binderfs is enabled these devices are now created in the binderfs instance instead. For full backwards compatibility with old Android versions symlinks (or bind mounts) can be provided in the host's devtmpfs. This is what I recommended a few months ago. > And we enabled it because, well, enabling things generally gives more > coverage. I guess I will disable CONFIG_ANDROID_BINDERFS for now to I would at least try to test both somehow. It's likely that binderfs will replace legacy binder devices so if we could keep testing it somehow that would be great. > restore coverage in the binder itself. I'm not completely sure what you mean here. The binder IPC codepaths are nearly the same. The difference is mostly in how the device information is cast out before actual binder-ipc operations take place. In any case, testing both would obviously be preferred but binderfs strikes me as more worthy of testing. Christian _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-01-26 9:51 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-25 17:49 binderfs interferes with syzkaller? Dmitry Vyukov 2020-01-25 17:49 ` Dmitry Vyukov 2020-01-25 18:13 ` Dmitry Vyukov 2020-01-25 18:13 ` Dmitry Vyukov 2020-01-26 9:51 ` Christian Brauner [this message] 2020-01-26 9:51 ` Christian Brauner 2020-01-27 17:11 ` Dmitry Vyukov 2020-01-27 17:11 ` Dmitry Vyukov 2020-01-26 8:55 ` Greg Kroah-Hartman 2020-01-26 8:55 ` Greg Kroah-Hartman 2020-01-26 9:35 ` Christian Brauner 2020-01-26 9:35 ` Christian Brauner 2020-01-28 13:46 ` Eric W. Biederman 2020-01-28 13:46 ` Eric W. Biederman 2020-01-28 13:54 ` Christian Brauner 2020-01-28 13:54 ` Christian Brauner 2020-01-27 16:47 ` Todd Kjos 2020-01-27 16:47 ` Todd Kjos
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=20200126095132.bq33azq7paqvedzx@wittgenstein \ --to=christian.brauner@ubuntu.com \ --cc=arve@android.com \ --cc=christian@brauner.io \ --cc=devel@driverdev.osuosl.org \ --cc=dvyukov@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=hridya@google.com \ --cc=joel@joelfernandes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maco@android.com \ --cc=syzkaller@googlegroups.com \ --cc=tkjos@android.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: linkBe 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.