linux-kernel - Re: [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot

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: <68e85e503ae05_29801003f@dwillia2-mobl4.notmuch>
Date: Thu, 9 Oct 2025 18:16:00 -0700
From: <dan.j.williams@...el.com>
To: Sean Christopherson <seanjc@...gle.com>, Chao Gao <chao.gao@...el.com>
CC: <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: VMX: Flush shadow VMCS on emergency reboot

Sean Christopherson wrote:
> Trimmed Cc: to lists, as this is basically off-topic, but I thought you might
> be amused :-)
> 
> On Thu, Apr 10, 2025, Sean Christopherson wrote:
> > On Mon, Mar 24, 2025, Chao Gao wrote:
> > > Ensure the shadow VMCS cache is evicted during an emergency reboot to
> > > prevent potential memory corruption if the cache is evicted after reboot.
> > 
> > I don't suppose Intel would want to go on record and state what CPUs would actually
> > be affected by this bug.  My understanding is that Intel has never shipped a CPU
> > that caches shadow VMCS state.
> > 
> > On a very related topic, doesn't SPR+ now flush the VMCS caches on VMXOFF?  If
> > that's going to be the architectural behavior going forward, will that behavior
> > be enumerated to software?  Regardless of whether there's software enumeration,
> > I would like to have the emergency disable path depend on that behavior.  In part
> > to gain confidence that SEAM VMCSes won't screw over kdump, but also in light of
> > this bug.
> 
> Apparently I completely purged it from my memory, but while poking through an
> internal branch related to moving VMXON out of KVM, I came across this:

Hey, while we on the topic of being off topic about that branch, I
mentioned to Chao that I was looking to post patches for a simple VMX
module. He pointed me here to say "I think Sean is already working on
it". This posting would be to save you the trouble of untangling that
branch, at least in the near term.

Here's the work-in-progress shortlog:

Chao Gao (2):
      x86/virt/tdx: Move TDX per-CPU initialization into tdx_enable()
      coco/tdx-host: Introduce a "tdx_host" device

Dan Williams (5):
      x86/virt/tdx: Drop KVM_INTEL dependency
      x86/reboot: Convert cpu_emergency_disable_virtualization() to notifier chain
      x86/reboot: Introduce CONFIG_VIRT_X86
      KVM: VMX: Rename vmx_init() to kvm_vmx_init()
      KVM: VMX: Move VMX from kvm_intel.ko to vmx.ko

I can put the finishing touches on it and send it out against
kvm-x86/next after -rc1 is out, or hold off if your extraction is going
ok.

> --
> Author:     Sean Christopherson <seanjc@...gle.com>
> AuthorDate: Wed Jan 17 16:19:28 2024 -0800
> Commit:     Sean Christopherson <seanjc@...gle.com>
> CommitDate: Fri Jan 26 13:16:31 2024 -0800
> 
>     KVM: VMX: VMCLEAR loaded shadow VMCSes on kexec()
>     
>     Add a helper to VMCLEAR _all_ loaded VMCSes in a loaded_vmcs pair, and use
>     it when doing VMCLEAR before kexec() after a crash to fix a (likely benign)
>     bug where KVM neglects to VMCLEAR loaded shadow VMCSes.  The bug is likely
>     benign as existing Intel CPUs don't insert shadow VMCSes into the VMCS
>     cache, i.e. shadow VMCSes can't be evicted since they're never cached, and
>     thus won't clobber memory in the new kernel.
> 
> --

At least my approach to the VMX module leaves VMCS clearing with KVM.
Main goal is not regress any sequencing around VMX.