On Thu, Sep 01, 2022 at 11:35:10AM -0700, Jim Mattson wrote: > On Thu, Sep 1, 2022 at 10:46 AM Pawan Gupta <pawan.kumar.gupta@xxxxxxxxx> wrote: > > > > On Wed, Aug 31, 2022 at 04:22:03PM +0800, Chao Gao wrote: > > > On Tue, Aug 30, 2022 at 04:42:19PM -0700, Jim Mattson wrote: > > > >Don't we need a software BHB-clearing sequence on VM-exit for Intel > > > >parts that don't report IA32_ARCH_CAPABILITIES.BHI_NO? What am I > > > >missing? > > > > > > I think we need the software mitigation on parts that don't support/enable > > > BHI_DIS_S of IA32_SPEC_CTRL MSR and don't enumerate BHI_NO. > > > > > > Pawan, any idea? > > > > Intel doesn't recommend any BHI mitigation on VM exit. The guest can't > > make risky system calls (e.g. unprivileged eBPF) in the host, so the > > previously proposed attacks aren't viable, and in general the exposed > > attack surface to a guest is much smaller (with no syscalls). If > > defense-in-depth paranoia is desired, the BHB-clearing sequence could be > > an alternative in the absence of BHI_DIS_S/BHI_NO. > > Just for clarity, are you saying that it is not possible for a guest > to use the shared BHB to mount a successful attack on the host when > eIBRS is enabled or IBRS is applied after VM-exit? It may be possible to use shared BHB to influence the choice of indirect targets, but there are other requirements that needs to be satisfied such as: - Finding a disclosure gadget. - Controlling register inputs to the gadget. - Injecting the disclosure gadget in the predictors before it can be transiently executed. - Finding an appropriate indirect-branch site after VM-exit, and before BHB is overwritten. IFAIK, other than gadgets based on unprivileged eBPF (which is disabled by default), previous research hasn't concluded on the exploitability of any other gadgets. Also factors stated above makes it hard for a guest to exploit BHI. If that changes or if defense-in-depth is desired, BHB-clearing sequence is the appropriate thing to do. Thanks, Pawan
