all: lpc24 requests

[tarasmadan]

Feature requests.

• Directed fuzzing to test local changes before submit (+docs). syz-diff: patch fuzzing improvements #5448
• Mixed log looks better for some users.
• Syz-manager requires restart for every configuration change.
• KVM + ARM64 syzbot setup was tricky. Let's simplify the first steps.
• syzbot: users need better access to reproducers #5345
• Distros asked for the testing (Neal Gompa from Fedora). Fedora is ahead wrt to compiler+flags. There are many systems (CKI, KernelCI etc.) - it seems better to export reproducers.
• Theodore Tso asked to FSCK the used filesystems add filter reports by fsck by result. Tracked in syzkaller, syzbot: attach fsck results to bug reports #5494.
• CC the regressions bot on bugs on linux-next and in the current release.
• pkg/kcidb: better integration #5324
• better coverage for j1939, in particular cover j1939/transport.c
• revive Binder fuzzing
• fuzz Rust Binder driver in the Android tree
• add KASAN support for DMA-related bugs.
• check if we can add ASSERT_EXCLUSIVE_WRITER/ACCESS to some common functions (rcu, pcpu, ...) (these bugs may have higher prio than other KCSAN reports).

Additional context
These requests were mostly received at https://lpc.events/event/18/contributions/1854/, video

[tarasmadan]

@a-nogikh @ramosian-glider @melver @dvyukov feel free to edit the first message

[dvyukov]

Syz-manager requires restart for every configuration change.

@a-nogikh do you remember what parameters do they want to change?

[dvyukov]

KVM + ARM64 syzbot setup was tricky. Let's simplify the first steps.

IIRC this was only about providing instructions for KVM mode.

[dvyukov]

Distros asked for the testing (Neal Gompa from Fedora). Fedora is ahead wrt to compiler+flags. There are many systems (CKI, KernelCI etc.) - it seems better to export reproducers.

We already have the repro, but none of the existing CIs use them AFAIK (+KernelCI does not report any bugs proactively).
So we consider fuzzing Fedora as well (on top of reviving export of reproducers as tests, so probably it's better to have these as separate bullets).
For the repro export, we should also add a script to run them (can check what LTP had) + add instructions on how to configure kernel and check for errors (otherwise most users may run repros on prod kernel + ignore even what that config will trigger). The wrapper script itself could probably grep dmesg.

[a-nogikh]

Syz-manager requires restart for every configuration change.

@a-nogikh do you remember what parameters do they want to change?

As far as I remember, that was more about the coverage filter (or also syscall filtering?). And that's unfortunately the trickiest option, after a change in which we actually have to retriage the whole corpus, which is essentially the same as just restarting the instance.

We could theoretically move signal filtering out of syz-executor, which will make things a bit simpler. But it won't bring back the programs discarded during the corpus triage.

[dvyukov]

As far as I remember, that was more about the coverage filter (or also syscall filtering?). And that's unfortunately the trickiest option, after a change in which we actually have to retriage the whole corpus, which is essentially the same as just restarting the instance.

Agree, it's unclear what's the win here. The only one I see is interrupted/lost bug reproductions.

[novitoll]

better coverage for j1939, in particular cover j1939/transport.c

FYI, for my first work with syz corpus, I'd like to take this CAN j1939 coverage, it's currently 3%. Let me create the draft PR once it's ready, so that you can link it in bulletpoints. Hopefully, it won't be hard to build a kernel with it.

[dvyukov]

better coverage for j1939, in particular cover j1939/transport.c

FYI, for my first work with syz corpus, I'd like to take this CAN j1939 coverage, it's currently 3%. Let me create the draft PR once it's ready, so that you can link it in bulletpoints. Hopefully, it won't be hard to build a kernel with it.

Oh, that would be great. I've talked to @olerem at LPC (Oleksij is j1939 maintainer, so you can ask Oleksij further questions). Here is what I recorded.
To get coverage in transport.c we need 2 can_j1939 sockets bound to the same vcan device, one needs to send message to another. We may have everything we need in descriptions (but to be confirmed). Potentially we only missing good seeds.
Here is approx seed (adapted from sys/linux/test/can):

r0 = socket$can_j1939(AUTO, AUTO, AUTO)
ioctl$ifreq_SIOCGIFINDEX_vcan(r0, AUTO, &AUTO={'vcan0\x00', <r1=>0x0})
bind$can_j1939(r0, &AUTO={AUTO, r1, 0x0, {0x0, 0x0, 0x0, 0x0}, 0x1}, AUTO)
r2 = socket$can_j1939(AUTO, AUTO, AUTO)
ioctl$ifreq_SIOCGIFINDEX_vcan(r2, AUTO, &AUTO={'vcan0\x00', <r3=>0x0})
bind$can_j1939(r2, &AUTO={AUTO, r3, 0x0, {0x0, 0x0, 0x0, 0x0}, 0x2}, AUTO)
connect$can_j1939(r2, &AUTO={AUTO, r3, 0x0, {0x0, 0x0, 0x0, 0x0}, 0x1}, AUTO)
send(r2, &AUTO='data', AUTO, 0x0)
recv(r0, &AUTO='----', AUTO, 0x0)

I have not tried to compile it, nor ensured that it actually covers transport.c yet (can be done with tools/syz-execprog -cover).