memn0ps / illusion-rs Goto Github PK

Add support for Intel Processor Trace (Intel PT) to enhance tracing and debugging capabilities in the hypervisor.

The hypervisor previously supported multiple cores, but recent changes have disrupted this functionality. The goal is to restore effective multi-core support and ensure the main branch is stable for production use. This includes identifying and fixing any bugs introduced during these changes, and ensuring the overall stability and reliability of the hypervisor.

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.

Add support for hardware-assisted breakpoints using CPU debug registers to enhance debugging capabilities in the hypervisor.

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.

Add support for hidden Interrupt Descriptor Table (IDT) hooks to enhance the hypervisor's capability to intercept and manage interrupt and exception handling more efficiently.

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.

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

Implement a CPUID password-protected backdoor to communicate with the hypervisor from user-mode and perform certain tasks. This feature could include:

• Telling the hypervisor to perform hooks or unhooks.
• Other tasks as required.

This enhancement will allow secure communication with the hypervisor for specialized tasks.

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…

Ensure that EPT hooks function correctly when targeting the same page. When splitting 2MB pages into 4KB pages using the same pre-allocated Page Table (PT), it can cause an issue. Or when multiple hooks require a shadow page, it's essential that they share a single shadow page rather than each having its distinct shadow page. This requirement is crucial for the hooks to operate correctly and could potentially cause issues with the current setup if not handled properly.

We need a better way to manage and keep track of hooks, utilizing guest_page_pa to consistently track associated shadow pages and PTs. Investigate and refine our approach to guarantee the stability and effectiveness of EPT hooks, particularly after integrating a communication method to perform hooks/unhooks from user-mode, as noted in issue #20.

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.

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.

The current memory allocator and tracking system have limitations that need to be addressed. The hypervisor should aim to record all memory allocations directly within GlobalAlloc and utilize fixed-size heap allocators to improve efficiency and reliability.