Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

manager: detect lost connection when executor gets killed #5028

Open
xairy opened this issue Jul 11, 2024 · 0 comments
Open

manager: detect lost connection when executor gets killed #5028

xairy opened this issue Jul 11, 2024 · 0 comments
Labels

Comments

@xairy
Copy link
Collaborator

xairy commented Jul 11, 2024

When fuzzing the USB HID drivers, I noticed that most of the time is being spent on rebooting VMs without any detected crashes and before the normal 1 hour timeout passes:

2024/07/11 15:34:03 vm-1: running for 48.399456145s, restarting
...

What happens is that due to #5027, the executor process gets killed all the time due to Ctrl+Alt+Del.

Fixing that issue should solve the problem of executor getting killed, however, I think syz-manager needs to detect such cases as lost connection to allow identifying and fixing them if they happen again in the future (or possibly already happening right now).

The reason syz-manager ignores the executor getting killed is because the executor prints SYZ-EXECUTOR: PREEMPTED before exiting:

# ./syz-execprog -enable=usb -repeat=0 -procs=1 -debug ./log
...
SYZ-EXECUTOR: PREEMPTED (errno 9)
executor process exited: exit status 1

Thus, extractError in vm/vm.go just exits on the executorPreemptedStr check.

The comment in executor/executor_runner.h says that this is related to GCE VM preemption:

static void SigintHandler(int sig)
{
	// GCE VM preemption is signalled as SIGINT, notify syz-manager.
	exitf("SYZ-EXECUTOR: PREEMPTED");
}

But this is not the case here, as I'm using QEMU.

Commenting out the executorPreemptedStr check in extractError makes syz-manager to detect the lost connection as expected, but I assume this is not the proper fix.

@xairy xairy added the bug label Jul 11, 2024
dvyukov added a commit to dvyukov/syzkaller that referenced this issue Jul 23, 2024
Pass Type struct directly during registration.
This allows to add additional optional parameters to VM types
without changing all VM implementations.
We we will need to add SupportsSnapshots flag and one flag to resolve google#5028.
With this change it will be possible to add "SupportsSnapshots: true"
to just one VM type implemenetation.
dvyukov added a commit to dvyukov/syzkaller that referenced this issue Jul 23, 2024
dvyukov added a commit to dvyukov/syzkaller that referenced this issue Jul 23, 2024
Pass Type struct directly during registration.
This allows to add additional optional parameters to VM types
without changing all VM implementations.
We we will need to add SupportsSnapshots flag and one flag to resolve google#5028.
With this change it will be possible to add "SupportsSnapshots: true"
to just one VM type implemenetation.
dvyukov added a commit to dvyukov/syzkaller that referenced this issue Jul 23, 2024
dvyukov added a commit to dvyukov/syzkaller that referenced this issue Jul 23, 2024
Pass Type struct directly during registration.
This allows to add additional optional parameters to VM types
without changing all VM implementations.
We we will need to add SupportsSnapshots flag and one flag to resolve google#5028.
With this change it will be possible to add "SupportsSnapshots: true"
to just one VM type implemenetation.
dvyukov added a commit to dvyukov/syzkaller that referenced this issue Jul 23, 2024
github-merge-queue bot pushed a commit that referenced this issue Jul 23, 2024
Pass Type struct directly during registration.
This allows to add additional optional parameters to VM types
without changing all VM implementations.
We we will need to add SupportsSnapshots flag and one flag to resolve #5028.
With this change it will be possible to add "SupportsSnapshots: true"
to just one VM type implemenetation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant