DLKM random load addresses + Syzkaller

[Joey Jiao]

Hi Dmitry,

In https://groups.google.com/g/syzkaller/c/1Pnm_BjrZO8/m/7ZJzJn6RBAAJ, we talked about a way to load modules into fixed addresses. however, it doesn't work for newer GKI enabled target. And the kernel team thinks it's not an option to move the modules back into vmlinux too.

I think it might be the same case for pixel, but it needs confirmation from @mspector.

So I bring up this topic again but for syzkaller modification disucssion.

Ideas on the new changes might be introduced?

Attached pic is the modification I can think of, color in red.

The idea is to convert pc (also pc used in signal `func: write_coverage_signal` in syz-executor) to 1st_module_load_address + pc_offset. (pc_offset = pc - 2nd+_reboot_module_load_address).

The 1st_module_load_address from 1st connected VM will be used for other VMs too.

THX

Joey

[Joey Jiao]

I think we still need to keep this option at least in mind at the moment, right?

Comment?

[Dmitry Vyukov]

Hi Joey,

I am thinking if we could move canonicalization of modules from syz-executor to syz-manager. This would be better for 2 reasons: (1) move it out from hot path (better performance as we discard most coverage since it's not "new"), (2) less code in C in executor, more code in Go (also better for https://github.com/google/syzkaller/issues/1541).

Namely, everything within a VM (executor, fuzzer) operate with unmodified PCs as they do now; syz-manager canonicalizes all incoming coverage from a VM (it already accepts module map from every VM, so it knows where modules are loaded in every VM), and de-canonicalizes back when it sends any coverage to a VM.

I think this could work nicely except for the "signal" which is hash of 2 consecutive PCs:

https://github.com/google/syzkaller/blob/31a30fc092d1c25b565a00465f075408677e8c54/executor/executor.cc#L928

This hash cannot be canonicalized later (at least I don't see how).

So I am thinking if we could just remove this "signal" from syzkaller entirely and just use PCs as the fuzzing signal. But this requires some benchmarking to make sure it won't significantly affect fuzzing negatively.

[Joey Jiao]

Hi Dmitry,

I didn't get this sentense

```

and de-canonicalizes back when it sends any coverage to a VM.

```

Why syz-manager needs send any coverage to a VM, I thought it only send corpus to VM? Why sending back signal is needed, is it used for triageInput?

Also, if there is no need to decode pc/signal on syz-executor, we can simply pass the trace pc area bitmap to syz-manager for decoding?

I think we still need the signal there, at least from AFL paper, it's the magic thing for fuzzing efficiency.

But from the #1541 PR, it sounds like the re-arch cannot be finished within months?

THX

Joey

[Dmitry Vyukov]

On Fri, 19 Nov 2021 at 06:02, Joey Jiao <joey....@gmail.com> wrote:
>
> Hi Dmitry,
> I didn't get this sentense
> ```
> and de-canonicalizes back when it sends any coverage to a VM.
> ```
> Why syz-manager needs send any coverage to a VM, I thought it only send corpus to VM? Why sending back signal is needed, is it used for triageInput?

The check if an inputs gives us new coverage or not happens in the
syz-fuzzer in the VM, not in the manager on the host. So the VM needs
to know the current corpus coverage. So manager sends coverage to new
VMs when they start.

> Also, if there is no need to decode pc/signal on syz-executor, we can simply pass the trace pc area bitmap to syz-manager for decoding?

We want to do the check if an inputs gives us new coverage or not in
the target VM. I think it would be too costly to send all coverage
from all programs to the host to do this check.
VMs only send new interesting programs+coverage to the host manager.

> I think we still need the signal there, at least from AFL paper, it's the magic thing for fuzzing efficiency.

The idea is to use coverage as fuzzing signal. What's what most fuzzers do.

> But from the #1541 PR, it sounds like the re-arch cannot be finished within months?

Yes, it's large and not planned at the moment.

> THX
> Joey
>
> 在2021年11月18日星期四 UTC+8 下午9:47:56<Dmitry Vyukov> 写道：
>>
>> Hi Joey,
>>
>> I am thinking if we could move canonicalization of modules from syz-executor to syz-manager. This would be better for 2 reasons: (1) move it out from hot path (better performance as we discard most coverage since it's not "new"), (2) less code in C in executor, more code in Go (also better for https://github.com/google/syzkaller/issues/1541).
>>
>> Namely, everything within a VM (executor, fuzzer) operate with unmodified PCs as they do now; syz-manager canonicalizes all incoming coverage from a VM (it already accepts module map from every VM, so it knows where modules are loaded in every VM), and de-canonicalizes back when it sends any coverage to a VM.
>>
>> I think this could work nicely except for the "signal" which is hash of 2 consecutive PCs:
>> https://github.com/google/syzkaller/blob/31a30fc092d1c25b565a00465f075408677e8c54/executor/executor.cc#L928
>> This hash cannot be canonicalized later (at least I don't see how).
>> So I am thinking if we could just remove this "signal" from syzkaller entirely and just use PCs as the fuzzing signal. But this requires some benchmarking to make sure it won't significantly affect fuzzing negatively.
>>
>>
>>
>> On Thu, 18 Nov 2021 at 12:56, Joey Jiao <joey....@gmail.com> wrote:
>>>
>>> I think we still need to keep this option at least in mind at the moment, right?
>>>
>>> Comment?
>>> 在2021年11月17日星期三 UTC+8 下午5:34:52<Joey Jiao> 写道：
>>>>
>>>> Hi Dmitry,
>>>> In https://groups.google.com/g/syzkaller/c/1Pnm_BjrZO8/m/7ZJzJn6RBAAJ, we talked about a way to load modules into fixed addresses. however, it doesn't work for newer GKI enabled target. And the kernel team thinks it's not an option to move the modules back into vmlinux too.
>>>> I think it might be the same case for pixel, but it needs confirmation from @mspector.
>>>>
>>>> So I bring up this topic again but for syzkaller modification disucssion.
>>>> Ideas on the new changes might be introduced?
>>>>
>>>> Attached pic is the modification I can think of, color in red.
>>>> The idea is to convert pc (also pc used in signal `func: write_coverage_signal` in syz-executor) to 1st_module_load_address + pc_offset. (pc_offset = pc - 2nd+_reboot_module_load_address).
>>>> The 1st_module_load_address from 1st connected VM will be used for other VMs too.
>>>>
>>>>

>>>> THX
>>>> Joey
>>>
>>>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/2d6965a4-3595-4c3a-8cc3-f8b8fea9e83fn%40googlegroups.com.