Re: KVM's sloppiness wrt IA32_SPEC_CTRL and IA32_PRED_CMD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

> But, I don't think there is a guarantee that future mitigations would
> not allow a malicious guest to compromise code running on sibling. To
> avoid this, care must be taken to add such mitigations to other MSRs
> that are not exported to guests.

Can you make sure that the right people at Intel get that message?




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux