On Fri, Jul 21, 2023 at 12:01 PM Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx> wrote: > > On Fri, Jul 21, 2023 at 11:37:42AM +0800, Chao Gao wrote: > > On Thu, Jul 20, 2023 at 10:52:44AM -0700, Jim Mattson wrote: > > >> And is it fair to good citizens that won't set reserved bits but will > > >> suffer performance drop caused by the fix? > > > > > >Is it fair to other tenants of the host to have their data exfiltrated > > >by a bad citizen, because KVM didn't control access to the MSR? > > > > To be clear, I agree to intercept IA32_SPEC_CTRL MSR if allowing guests > > to clear some bits puts host or other tenents at risk. > > > > >> >As your colleague pointed out earlier, IA32_SPEC_CTRL.STIBP[bit 1] is > > >> >such a bit. If the host has this bit set and you allow the guest to > > >> >clear it, then you have compromised host security. > > > > ... > > > > >> > > >> If guest can compromise host security, I definitly agree to intercept > > >> IA32_SPEC_CTRL MSR. > > > > > >I believe that when the decision was made to pass through this MSR for > > >write, the assumption was that the host wouldn't ever use it (hence > > >the host value would be zero). That assumption has not stood the test > > >of time. > > > > Could you elaborate on the security risk of guests' clearing > > IA32_SPEC_CTRL.STIBP[bit 1] (or any other bit)? +Pawan > > 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?
