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: <CABgObfaSGOt4AKRF5WEJt2fGMj_hLXd7J2x2etce2ymvT4HkpA@mail.gmail.com>
Date: Mon, 26 Feb 2024 15:49:34 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Lai Jiangshan <jiangshanlai@...il.com>
Cc: linux-kernel@...r.kernel.org, Lai Jiangshan <jiangshan.ljs@...group.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>, 
	Sean Christopherson <seanjc@...gle.com>, 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 Mon, Feb 26, 2024 at 3:34 PM Lai Jiangshan <jiangshanlai@...il.com> wrote:
> - Full control: In XENPV/Lguest, the host Linux (dom0) entry code is
>   subordinate to the hypervisor/switcher, and the host Linux kernel
>   loses control over the entry code. This can cause inconvenience if
>   there is a need to update something when there is a bug in the
>   switcher or hardware.  Integral entry gives the control back to the
>   host kernel.
>
> - Zero overhead incurred: The integrated entry code doesn't cause any
>   overhead in host Linux entry path, thanks to the discreet design with
>   PVM code in the switcher, where the PVM path is bypassed on host events.
>   While in XENPV/Lguest, host events must be handled by the
>   hypervisor/switcher before being processed.

Lguest... Now that's a name I haven't heard in a long time. :)  To be
honest, it's a bit weird to see yet another PV hypervisor. I think
what really killed Xen PV was the impossibility to protect from
various speculation side channel attacks, and I would like to
understand how PVM fares here.

You obviously did a great job in implementing this within the KVM
framework; the changes in arch/x86/ are impressively small. On the
other hand this means it's also not really my call to decide whether
this is suitable for merging upstream. The bulk of the changes are
really in arch/x86/kernel/ and arch/x86/entry/, and those are well
outside my maintenance area.

Paolo