memn0ps / illusion-rs Goto Github PK

Issue: Support for running as a nested hypervisor under Microsoft Hyper-V with Virtualization Based Security (VBS).

Environment: UEFI Rust hypervisor, with partial support for Hyper-V nested virtualization.

Current Status:

• Implemented: Out of Range MSRs and Hyper-V Interface CPUID Leaves.
• Pending:
  1. Implementation of Hyper-V Hypercalls (VMCALLs).
  2. Transition to Advanced Configuration and Power Interface (ACPI) from the older Multiprocessor Specification (MP Protocol).

Required Implementation:

1. Hyper-V Hypercalls (VMCALLs) - Essential for managing interactions between the hypervisor and the nested virtual machine (VM). This includes recognizing and correctly handling VMCALLs from both the hypervisor and nested VMs to maintain system stability and functionality.
2. Advanced Configuration and Power Interface (ACPI) - Transition from MP Protocol to ACPI is necessary to meet Hyper-V's configuration and power management standards.

Current Behavior: Without proper VMCALL handling and ACPI support, the hypervisor cannot correctly interact with Hyper-V, leading to potential failures or incorrect operations under Hyper-V nested virtualization.

Expected Behavior:

• The hypervisor should intercept and manage VMCALLs effectively, ensuring smooth operation and compatibility within a Hyper-V environment.
• Transition to ACPI support to enhance compatibility with Hyper-V's power management and configuration requirements.

Steps to Reproduce:

1. Set up the hypervisor with Hyper-V.
2. Observe operational issues related to unhandled VMCALLs and potential issues due to MP Protocol usage instead of ACPI.

Additional Information:
Implementing these functionalities is crucial for ensuring that the hypervisor can run efficiently under Hyper-V, handling all necessary hypercalls and configuration protocols as expected by the Hyper-V Hypervisor Top-Level Functional Specification (TLFS). Transitioning to ACPI will address compatibility issues with Hyper-V's advanced power management features.

Plan to explore AMD support with Nested Page Tables (NPT) in the future, aiming for implementation within one year.

The Windows hypervisor matrix-rs hook mechanism in the library relies on INT3, which causes VM exits and potential performance issues. To offer users flexibility, the hypervisor needs to support JMP, INT3, VMCALL, and CPUID hooks, allowing them to choose the preferred method based on their requirements. Additionally, supporting relative JMP hooks is essential for improved efficiency. Careful consideration should be given to selecting the appropriate library for hooking implementation.

Note: INT3, VMCALL, CPUID hooks will cause a vmexit.

Careful consideration should be given to allocating and executing the trampoline, which would be allocated in the host address space unless specified otherwise. This would disallow the guest to execute the allocated trampoline on the host PA space unless the guest itself allocates memory, but that would expose the trampoline. Alternative ways should be explored e.g Manipulation of EPT…

Implement support for nested virtualization, enabling the hypervisor to run on top of Hyper-V while ensuring compatibility and performance.

Avoid using the x86 crate overall and develop the necessary functionality from scratch. This approach will facilitate learning and reduce dependence on external libraries, potentially increasing accuracy. However, it may require more effort. This task is optional and not urgent.

Errors in the hypervisor are typically handled using a custom error type, HypervisorError, through Result or Option. Despite this, errors default to causing a panic in the vmm.rs file, particularly during critical issues that necessitate halting the hypervisor. This panic approach, while highlighting problems quickly, isn't always ideal, especially when a graceful shutdown would be preferable. It can hinder debugging and disrupt processes unnecessarily, although there are cases where shutting down the hypervisor isn't desired, and panicking is the preferred option. I personally prefer handling all errors with a custom error type, returning Result<(), HypervisorError>, and funneling them to a single location in the main function (vmm.rs). If an error cannot be handled and I no longer want the hypervisor running or off, I opt for panicking the Windows guest OS (BSOD).

To improve the hypervisor's adaptability and robustness, a mechanism for a graceful shutdown and CPU devirtualization could be a better option. This would involve executing VMXOFF to cleanly exit VMX operation, restoring any altered states during VMXON, and orderly devirtualizing CPUs.

Integrate Windows (Kernel Driver) with the UEFI (Runtime Driver) hypervisor to allow users the option to build the software as either a kernel driver or a UEFI runtime driver, providing flexibility in deployment options.

Issue: Serial logs stop updating after Windows OS boots, although the hypervisor continues to run.

Expected Behavior: Serial logs should continue to output after Windows OS boots.

Actual Behavior: Logs freeze upon Windows boot.

Steps to Reproduce:

1. Boot Windows OS in the hypervisor environment.
2. Observe the serial logs.

Additional Info: Hypervisor remains operational; issue only affects log visibility.