linux-kernel - Re: KVM default behavior change on module loading in kernel 6.12

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] [day] [month] [year] [list]

Message-ID: <CABgObfYWZQc_gnzUAmFQ=McbN4VQxbrd+4vss=pGRdrOAcOcfg@mail.gmail.com>
Date: Wed, 9 Oct 2024 14:17:47 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Vadim Galitsin <vadim.galitsyn@...cle.com>, Klaus Espenlaub <klaus.espenlaub@...cle.com>, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: KVM default behavior change on module loading in kernel 6.12

On Mon, Oct 7, 2024 at 8:07 PM Sean Christopherson <seanjc@...gle.com> wrote:
> On Mon, Oct 07, 2024, Vadim Galitsin wrote:
> > Would you consider to change the default behavior by having
> > "kvm.enable_virt_at_load=0", so people who really need it, could explicitly
> > enable it in kernel command line?
>
> I'm not dead set against it, but my preference would be to force out-of-tree
> hypervisor modules to adjust.  Leaving enable_virt_at_load off by default risks
> performance regressions due to the CPU hotplug framework serially operating on
> CPUs[1].  And, no offence to VirtualBox or VMware, I care much more about not
> regressing KVM users than I care about inconveniencing out-of-tree hypervisors.
>
> Long term, the right answer to this problem is to move virtualization enabling
> to a separate module (*very* roughly sketeched out here[2]), which would allow
> out-of-tree hypervisor modules to co-exist with KVM.  They would obviously need
> to give up control of CR4.VMXE/VMXON/EFER.SVME, but I don't think that's an
> unreasonable ask.

I agree, VMXE/VMXON/SVME are mostly a one-shot thing.

I thought about adding a Kconfig for kvm.enable_virt_at_load, but it
is not really a good solution.  Distros would either leave it to the
default of y and inconvenience VirtualBox/VMware users, or set it to n
and have bad performance on machines with a large number of CPUs. The
problem is that "all distros set it to y" is an unstable equilibrium,
because it may take only one bug report to convince distros to flip
the value.

> Short term, one idea would be to have VirtualBox's module (and others) prepare
> for that future by pinning kvm-{amd,intel}.ko, and then playing nice if VMX/SVM
> is already enabled.

Yes, this is a good plan for allowing to work with both old and new KVM.

Alternatively if VirtualBox or VMware have an installer or rpm they
can write a file to /etc/modprobe.d to change the default, which
doesn't require code changes but is not a good idea.

Paolo