Fault Injection connect question

[Wmingyu]

when i perform fault Injection test，i failed to connection qemu and reply Boot with module {device} failed!.How can i to solve？

[ZheyuMa]

Could you please show me how to reproduce the problem or a screenshot of it to help me locate it?

[Wmingyu]

Thank you for reply.My question is step 4 failed.How can i to resolve this question? At 2024-11-22 21:50:46, "Ma Zheyu" ***@***.***> wrote: Could you please show me how to reproduce the problem or a screenshot of it to help me locate it? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wmy-yyy]

In the fault injection part, I did not generate a success message, and all were crashes

[ZheyuMa]

As acknowledged in the paper, PrIntFuzz’s solution does not guarantee 100% success rate, there will be some cases that fail. You can test it on all drivers and then observe the examples in the success folder.

[Wmingyu]

Thank you. We only have 11 successful parts of PCI, most of which are failures, enter a failed emulation device to see that its driver is in use, what is the cause of this situation?

[ZheyuMa]

Sorry, I cannot reproduce the problem, everything is fine in my environment. Could you please provide the completed log from scratch so that I can locate the problem? BTW, "in use" means that the device emulation was successful, but it was misclassified.

[Wmingyu]

We have some problems with the fault injection part. When judging the success or not, "Kernel driver in use" cannot be output, but it can be viewed after entering the virtual device. Could you please explain what caused it?

[ZheyuMa]

This is weird. It looks like the lspci command reported an error in the first image but not in the second, can you confirm the reason for the error, please?

[Wmingyu]

Thank you very much for your reply, but so far I have not found the reason for the error. Let me try again and see if I can solve this problem.

[Wmingyu]

I'm sorry to bother you again, but I still have some questions to ask you.
I can't get the system call list for the interrupt section, and I can't find the 'new_fake_{device_name}.txt' and 'new_qemu_{device_name}.txt' files. How can I get the information about the interrupt section?

[ZheyuMa]

Thanks for reporting. This version only included the device emulation code, excluding the interrupt system call descriptions, I'll update the code as soon as you needed.

[Wmingyu]

Thank you. Now when I go to execute the "fuzz.py -s -f" script, output the message "SYZFAIL: Open print_fuzz failed" in the 'syzkaller.out' file. And should I check the final results in the "syzkaller_workdir/crashes report"?

[ZheyuMa]

No, you should check why the "printfuzz" module does not work. You can check whether the module is compiled to the kernel and the permission of the module.

[Wmingyu]

I'm sorry to bother you again. I re-did step 7 -"Build the disk image for fuzzing", and I checked for the "print_fuzz.o" file in the "build/linux/linux_fuzz" directory. Meanwhile, I did not find an operation in the python script to add "printfuzz" to the kernel. What should I do to make sure that the "printfuzz" module is included in the kernel? Or how do I check if “printfuzz” is in the kernel?

[Wmingyu]

I'm sorry to bother you again. Could you give us some examples of interruptions, even just one? I would really appreciate it, because it would be very helpful to our work

[ZheyuMa]

It looks like the module is compiled in, it could be something else, you need more detailed logs to locate the issue. Please double-check the cause of the error, an error reported by syzkaller is insufficient.

[ZheyuMa]

What kind of examples of interruptions do you want? The syzkaller description or something else. BTW, if there are any other questions please start a new issue, it looks clearer, thanks!