On Fri, Apr 11, 2025 at 09:57:55AM -0700, Sean Christopherson wrote: >On Fri, Apr 11, 2025, Chao Gao wrote: >> On Thu, Apr 10, 2025 at 02:55:29PM -0700, 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. >> >> I am not sure. Would you like me to check internally? > >Eh, if it's easy, it'd be nice to have, but don't put much effort into it. I'm >probably being too cute in hesitating about sending this to stable@. The risk >really shouldn't be high. I've raised this question internally and will get back once I have an answer. > >> However, SDM Chapter 26.11 includes a footnote stating: >> " >> As noted in Section 26.1, execution of the VMPTRLD instruction makes a VMCS is >> active. In addition, VM entry makes active any shadow VMCS referenced by the >> VMCS link pointer in the current VMCS. If a shadow VMCS is made active by VM >> entry, it is necessary to execute VMCLEAR for that VMCS before allowing that >> VMCS to become active on another logical processor. >> " >> >> To me, this suggests that shadow VMCS may be cached, and software shouldn't >> assume the CPU won't cache it. But, I don't know if this is the reality or >> if the statement is merely for hardware implementation flexibility. >> >> > >> >On a very related topic, doesn't SPR+ now flush the VMCS caches on VMXOFF? If >> >> Actually this behavior is not publicly documented. > >Well shoot. That should probably be remedied. Even if the behavior is guaranteed >only on CPUs that support SEAM, _that_ detail should be documented. I'm not >holding my breath on Intel allowing third party code in SEAM, but the mode _is_ >documented in the SDM, and so IMO, the SDM should also document how things like >clearing the VMCS cache are supposed to work when there are VMCSes that "untrusted" >software may not be able to access. I'm also inquiring whether all VMCSs are flushed or just SEAM VMCSs, and whether this behavior can be made public. A related topic is why KVM is flushing VMCSs. I haven't found any explicit statement in the SDM indicating that the flush is necessary. SDM chapter 26.11 mentions: If a logical processor leaves VMX operation, any VMCSs active on that logical processor may be corrupted (see below). To prevent such corruption of a VMCS that may be used either after a return to VMX operation or on another logical processor, software should execute VMCLEAR for that VMCS before executing the VMXOFF instruction or removing power from the processor (e.g., as part of a transition to the S3 and S4 power states). To me, the issue appears to be VMCS corruption after leaving VMX operation and the flush is necessary only if you intend to use the VMCS after re-entering VMX operation.
