linux-kernel - Re: [RFC PATCH 00/73] KVM: x86/PVM: Introduce a new hypervisor

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: <16781c35a30cc5d8548da66303b323436187bbd9.camel@infradead.org>
Date: Thu, 29 Feb 2024 10:33:24 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
 <pbonzini@...hat.com>
Cc: Lai Jiangshan <jiangshanlai@...il.com>, linux-kernel@...r.kernel.org, 
 Lai Jiangshan <jiangshan.ljs@...group.com>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>,
 Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Ingo
 Molnar <mingo@...hat.com>, kvm@...r.kernel.org,  x86@...nel.org, Kees Cook
 <keescook@...omium.org>, Juergen Gross <jgross@...e.com>,  Hou Wenlong
 <houwenlong.hwl@...group.com>
Subject: Re: [RFC PATCH 00/73] KVM: x86/PVM: Introduce a new hypervisor

On Tue, 2024-02-27 at 09:27 -0800, Sean Christopherson wrote:
> 
> The bulk of the pain with nested hardware virtualization lies in having to emulate
> VMX/SVM, and shadow L1's TDP page tables.  Hyper-V's eVMCS takes some of the sting
> off nVMX in particular, but eVMCS is still hobbled by its desire to be almost
> drop-in compatible with VMX.
> 
> If we're willing to define a fully PV interface between L0 and L1 hypervisors, I
> suspect we provide performance far, far better than nVMX/nSVM.  E.g. if L0 provides
> a hypercall to map an L2=>L1 GPA, then L0 doesn't need to shadow L1 TDP, and L1
> doesn't even need to maintain hardware-defined page tables, it can use whatever
> software-defined data structure best fits it needs.

I'd like to understand how, if at all, this intersects with the
requirements we have for pKVM on x86. For example, would pKVM run the
untrusted part of the kernel as a PVM guest using this model? Would the
PV interface of which you speak also map to the calls from the kernel
into the secure pKVM hypervisor... ?

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)