On Sat, Jan 25, 2020 at 6:49 PM Dmitry Vyukov <dvyukov@xxxxxxxxxx> 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? if (!IS_ENABLED(CONFIG_ANDROID_BINDERFS) && strcmp(binder_devices_param, "") != 0) { /* * Copy the module_parameter string, because we don't want to * tokenize it in-place. */ device_names = kstrdup(binder_devices_param, GFP_KERNEL); if (!device_names) { ret = -ENOMEM; goto err_alloc_device_names_failed; } device_tmp = device_names; while ((device_name = strsep(&device_tmp, ","))) { ret = init_binder_device(device_name); if (ret) goto err_init_binder_device_failed; } } And we enabled it because, well, enabling things generally gives more coverage. I guess I will disable CONFIG_ANDROID_BINDERFS for now to restore coverage in the binder itself. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
