Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

KVM: x86: Leave user-return notifier registered on reboot/shutdown

Leave KVM's user-return notifier registered in the unlikely case that the
notifier is registered when disabling virtualization via IPI callback in
response to reboot/shutdown. On reboot/shutdown, keeping the notifier
registered is ok as far as MSR state is concerned (arguably better then
restoring MSRs at an unknown point in time), as the callback will run
cleanly and restore host MSRs if the CPU manages to return to userspace
before the system goes down.

The only wrinkle is that if kvm.ko module unload manages to race with
reboot/shutdown, then leaving the notifier registered could lead to
use-after-free due to calling into unloaded kvm.ko module code. But such
a race is only possible on --forced reboot/shutdown, because otherwise
userspace tasks would be frozen before kvm_shutdown() is called, i.e. on a
"normal" reboot/shutdown, it should be impossible for the CPU to return to
userspace after kvm_shutdown().

Furthermore, on a --forced reboot/shutdown, unregistering the user-return
hook from IRQ context doesn't fully guard against use-after-free, because
KVM could immediately re-register the hook, e.g. if the IRQ arrives before
kvm_user_return_register_notifier() is called.

Rather than trying to guard against the IPI in the "normal" user-return
code, which is difficult and noisy, simply leave the user-return notifier
registered on a reboot, and bump the kvm.ko module refcount to defend
against a use-after-free due to kvm.ko unload racing against reboot.

Alternatively, KVM could allow kvm.ko and try to drop the notifiers during
kvm_x86_exit(), but that's also a can of worms as registration is per-CPU,
and so KVM would need to blast an IPI, and doing so while a reboot/shutdown
is in-progress is far risky than preventing userspace from unloading KVM.

Link: https://patch.msgid.link/20251030191528.3380553-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>

+15 -1
+15 -1
arch/x86/kvm/x86.c
··· 13108 13108 void kvm_arch_disable_virtualization_cpu(void) 13109 13109 { 13110 13110 kvm_x86_call(disable_virtualization_cpu)(); 13111 - drop_user_return_notifiers(); 13111 + 13112 + /* 13113 + * Leave the user-return notifiers as-is when disabling virtualization 13114 + * for reboot, i.e. when disabling via IPI function call, and instead 13115 + * pin kvm.ko (if it's a module) to defend against use-after-free (in 13116 + * the *very* unlikely scenario module unload is racing with reboot). 13117 + * On a forced reboot, tasks aren't frozen before shutdown, and so KVM 13118 + * could be actively modifying user-return MSR state when the IPI to 13119 + * disable virtualization arrives. Handle the extreme edge case here 13120 + * instead of trying to account for it in the normal flows. 13121 + */ 13122 + if (in_task() || WARN_ON_ONCE(!kvm_rebooting)) 13123 + drop_user_return_notifiers(); 13124 + else 13125 + __module_get(THIS_MODULE); 13112 13126 } 13113 13127 13114 13128 bool kvm_vcpu_is_reset_bsp(struct kvm_vcpu *vcpu)