UninitializedSandbox::init hangs if no permissions on /dev/kvm

[qbradley]

What happened?

When permissions are incorrect on /dev/kvm UninitializedSandbox::init hangs indefinately.

It appears that HypervisorHandlerAction::Initialise in HyperivsorHandler::start_hypervisor_handler does not send a response when the thread exits with an error. The error is returned from set_up_hypervisor_partition on line 300.

I would recommend moving the handler processing to a sub-function so that the main loop of the thread can return an error to the calling thread on any failure.

I would also recommend implementing some kind of panic handling, so that if this thread panics the client will get an error.

What did you expect to happen?

I expected to get an error.

Steps to reproduce the behavior

1. Run chmod 600 /dev/kvm (/dev/kvm is owned by root, so removing group read/write means I do not have access)
2. Call UninitializedSandbox::new(...)

Hyperlight Version

0.5.1

OS version

$ cat /etc/os-release
NAME="Microsoft Azure Linux"
VERSION="3.0.20250521"
ID=azurelinux
VERSION_ID="3.0"
PRETTY_NAME="Microsoft Azure Linux 3.0"
ANSI_COLOR="1;34"
HOME_URL="https://aka.ms/azurelinux"
BUG_REPORT_URL="https://aka.ms/azurelinux"
SUPPORT_URL="https://aka.ms/azurelinux"
$ uname -a
Linux 75b2257d5bbb 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Additional Information

No response

[ludfjig]

I tried this on 0.5.1 and am unable to reproduce it. The thread will hang for the duration specified in the SandboxConfiguration here, after which it will get the underlying error Error: Error("No Hypervisor was found for Sandbox, Hypervisor Handler Message Receive Timedout")

Regardless, #533 has removed the hypervisor thread along with all timeout-based cancellation, so it should not be a problem in the next release anyway.

[ludfjig]

Closing this since it will be solved in upcoming release, feel free to reopen otherwise