On Fri, Apr 24, 2020 at 02:37:44PM +0300, Jon Doron wrote:
> Microsoft's kdvm.dll dbgtransport module does not respect the hypercall
> page and simply identifies the CPU being used (AMD/Intel) and according
> to it simply makes hypercalls with the relevant instruction
> (vmmcall/vmcall respectively).
>
> The relevant function in kdvm is KdHvConnectHypervisor which first checks
> if the hypercall page has been enabled via HV_X64_MSR_HYPERCALL_ENABLE,
> and in case it was not it simply sets the HV_X64_MSR_GUEST_OS_ID to
> 0x1000101010001 which means:
> build_number = 0x0001
> service_version = 0x01
> minor_version = 0x01
> major_version = 0x01
> os_id = 0x00 (Undefined)
> vendor_id = 1 (Microsoft)
> os_type = 0 (A value of 0 indicates a proprietary, closed source OS)
>
> and starts issuing the hypercall without setting the hypercall page.
I guess this is to avoid interfering with the OS being debugged
requesting its own hypercall page at a different address.
> To resolve this issue simply enable hypercalls also if the guest_os_id
> is not 0 and the syndbg feature is enabled.
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
> Signed-off-by: Jon Doron <arilou@xxxxxxxxx>
> ---
> arch/x86/kvm/hyperv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 435516595090..524b5466a515 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -1650,7 +1650,10 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *current_vcpu, u64 ingpa, u64 outgpa,
>
> bool kvm_hv_hypercall_enabled(struct kvm *kvm)
> {
> - return READ_ONCE(kvm->arch.hyperv.hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE;
> + struct kvm_hv *hv = &kvm->arch.hyperv;
> +
> + return READ_ONCE(hv->hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE ||
> + (hv->hv_syndbg.active && READ_ONCE(hv->hv_guest_os_id) != 0);
This function is meant to tell if the hypercall should be interpreted as
following KVM or HyperV conventions. Quoting from the spec
3.5 Legal Hypercall Environments
...
All hypercalls should be invoked through the architecturally-defined
hypercall interface. (See the following sections for instructions on
discovering and establishing this interface.) An attempt to invoke a
hypercall by any other means (for example, copying the code from the
hypercall code page to an alternate location and executing it from
there) might result in an undefined operation (#UD) exception. The
hypervisor is not guaranteed to deliver this exception.
so I think we can simply test for hv_guest_os_id != 0 and ignore
HV_X64_MSR_HYPERCALL_ENABLE (it's about hypercall page being enabled,
not the hypercalls per se).
Thanks,
Roman.
> }
>
> static void kvm_hv_hypercall_set_result(struct kvm_vcpu *vcpu, u64 result)
> --
> 2.24.1
>
