linux-kernel - Re: [PATCH 2/3] KVM: x86: Add support for VMware guest specific hypercalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABgObfb3Ttfg6H+_RpNQGSYKw9BLEwx3+EysXdL-wbpd1pkGHQ@mail.gmail.com>
Date: Mon, 3 Feb 2025 19:21:47 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Doug Covelli <doug.covelli@...adcom.com>
Cc: Sean Christopherson <seanjc@...gle.com>, Zack Rusin <zack.rusin@...adcom.com>, 
	kvm <kvm@...r.kernel.org>, Jonathan Corbet <corbet@....net>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "the arch/x86 maintainers" <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, Shuah Khan <shuah@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Arnaldo Carvalho de Melo <acme@...hat.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Joel Stanley <joel@....id.au>, Linux Doc Mailing List <linux-doc@...r.kernel.org>, linux-kernel@...r.kernel.org, 
	linux-kselftest <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 2/3] KVM: x86: Add support for VMware guest specific hypercalls

On Mon, Feb 3, 2025 at 5:35 PM Doug Covelli <doug.covelli@...adcom.com> wrote:
> OK.  It seems like fully embracing the in-kernel APIC is the way to go
> especially considering it really simplifies using KVM's support for nested
> virtualization.  Speaking of nested virtualization we have been working on
> adding support for that and would like to propose a couple of changes:
>
> - Add an option for L0 to handle backdoor accesses from CPL3 code running in L2.
> On a #GP nested_vmx_l0_wants_exit can check if this option is enabled and KVM
> can handle the #GP like it would if it had been from L1 (exit to userlevel iff
> it is a backdoor access otherwwise deliver the fault to L2).  When combined with
> enable_vmware_backdoor this will allow L0 to optionally handle backdoor accesses
> from CPL3 code running in L2.  This is needed for cases such as running VMware
> tools in a Windows VM with VBS enabled.  For other cases such as running tools
> in a Windows VM in an ESX VM we still want L1 to handle the backdoor accesses
> from L2.

I think this makes sense and could be an argument to KVM_ENABLE_CAP.

> - Extend KVM_EXIT_MEMORY_FAULT for permission faults (e.g the guest attempting
> to write to a page that has been protected by userlevel calling mprotect).  This
> is useful for cases where we want synchronous detection of guest writes such as
> lazy snapshots (dirty page tracking is no good for this case).  Currently
> permission faults result in KVM_RUN returning EFAULT which we handle by
> interpreting the instruction as we do not know the guest physical address
> associated with the fault.

Yes, this makes sense too, though you might want to look into
userfaultfd as well.

We had something planned using attributes, but I don't see any issue
extending it to EFAULT. Maybe it would have to be yet another
KVM_ENABLE_CAP; considering that it would break your existing code,
there might be someone else in the wild doing it.

Paolo