On Fri, Jul 21, 2023 at 03:29:04PM -0700, Pawan Gupta wrote: > On Fri, Jul 21, 2023 at 03:18:12PM -0700, Jim Mattson wrote: > > On Fri, Jul 21, 2023 at 1:54 PM Pawan Gupta > > <pawan.kumar.gupta@xxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, Jul 21, 2023 at 12:18:36PM -0700, Jim Mattson wrote: > > > > > Please note that clearing STIBP bit on one thread does not disable STIBP > > > > > protection if the sibling has it set: > > > > > > > > > > Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor > > > > > prevents the predicted targets of indirect branches on any logical > > > > > processor of that core from being controlled by software that executes > > > > > (or executed previously) on another logical processor of the same core > > > > > [1]. > > > > > > > > I stand corrected. For completeness, then, is it true now and > > > > forevermore that passing IA32_SPEC_CTRL through to the guest for write > > > > can in no way compromise code running on the sibling thread? > > > > > > As IA32_SPEC_CTRL is a thread-scope MSR, a malicious guest would be able > > > to turn off the mitigation on its own thread only. Looking at the > > > current controls in this MSR, I don't see how a malicious guest can > > > compromise code running on sibling thread. > > > > Does this imply that where core-shared resources are affected (as with > > STIBP), the mitigation is enabled whenever at least one thread > > requests it? > > Let me check with CPU architects. For the controls present in IA32_SPEC_CTRL MSR, if atleast one of the thread has the mitigation enabled, current CPUs do not disable core-wide mitigations when core-shared resources are affected. This will be the guiding principle for future mitigation controls that may be added to IA32_SPEC_CTRL MSR.
