syzkaller icon indicating copy to clipboard operation
syzkaller copied to clipboard

executor: use different remote kcov handles each time

Open a-nogikh opened this issue 1 year ago • 4 comments

It serves two purposes:

  1. Ignore the remote coverage that was initiated by the already exited executor instances.
  2. Circumvent the KCOV bug that sometimes results in dangling remote kcov handles. The bug is fixed in [1], but it will take time for it to reach all the kernels we fuzz.

Fixes #4626.

[1] https://lore.kernel.org/all/[email protected]/

a-nogikh avatar Jun 12 '24 12:06 a-nogikh

This PR breaks usb fuzzing, since, apparently, the kernel always routes the usb coverage via a kcov remote handle that equals the usb device's bus number (?): For example, each hub_event worker uses the USB bus number as the task instance id. (from the docs).

@xairy, do you remember whether/where we can control the bus numbers of the usb devices we create for fuzzing? Can these be arbitrary uint32 numbers? Or do we really not want it because we e.g. cannot reliably clean up such devices after each executor restart?

a-nogikh avatar Jun 12 '24 12:06 a-nogikh

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 61.0%. Comparing base (f815599) to head (dc1bf5b). Report is 279 commits behind head on master.

Additional details and impacted files

see 1 file with indirect coverage changes

codecov[bot] avatar Jun 12 '24 12:06 codecov[bot]

This PR breaks usb fuzzing, since, apparently, the kernel always routes the usb coverage via a kcov remote handle that equals the usb device's bus number (?): For example, each hub_event worker uses the USB bus number as the task instance id. (from the docs).

@xairy, do you remember whether/where we can control the bus numbers of the usb devices we create for fuzzing? Can these be arbitrary uint32 numbers? Or do we really not want it because we e.g. cannot reliably clean up such devices after each executor restart?

We do not control the USB bus numbers, the dummy_hcd module creates them sequentially starting from 1. We pass dummy_hcd.num=N (N == proc) to the kernel command-line to make dummy_hcd create a bus for each executor. And the kernel USB code uses fixed KCOV handles derived from the bus numbers (see kcov_remote_start_usb).

So yeah, this change will break USB coverage collection.

xairy avatar Jun 13 '24 22:06 xairy

Ah, that's a pity. Then there's no chance to work around the lost kcov handles bug until the fix reaches the mainline.

Thanks for sharing the details!

a-nogikh avatar Jun 14 '24 09:06 a-nogikh