BHB-clearing on VM-exit

BHB-clearing on VM-exit

[Jim Mattson]

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?

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html

Re: BHB-clearing on VM-exit

[Chao Gao]

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?

>
>https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html

Re: BHB-clearing on VM-exit

[Pawan Gupta]

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.

Thanks,
Pawan

Re: BHB-clearing on VM-exit

[Jim Mattson]

On Thu, Sep 1, 2022 at 10:46 AM Pawan Gupta <pawan.kumar.gupta@intel.com> 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?

Re: BHB-clearing on VM-exit

[Pawan Gupta]

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@intel.com> 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

Re: BHB-clearing on VM-exit

[Jim Mattson]

On Fri, Sep 2, 2022 at 12:14 PM Pawan Gupta <pawan.kumar.gupta@intel.com> wrote:

> 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.

Gadgets abound, and there are tools to find them, if the attacker has
the victim binary.

>  - Controlling register inputs to the gadget.

This is non-trivial, since kvm clears GPRs on VM-exit. However, an
attacker can look for calls to kvm_read_register() or similar places
where kvm loads elements of guest state. The instruction emulator and
local APIC emulation both seem like promising targets.

>  - Injecting the disclosure gadget in the predictors before it can be
>    transiently executed.

IIUC, the gadget has to already be an indirect branch target that can
be exercised by some guest action (e.g. writing to a specific x2APIC
MSR). Is that correct?

>  - Finding an appropriate indirect-branch site after VM-exit, and before
>    BHB is overwritten.

Is it the case that the RIP of the victim indirect branch has to alias
to the RIP of the "training branch" above in the predictors?

Presumably, guest influence diminishes after every branch, even before
the BHB is completely overwritten.

Re: BHB-clearing on VM-exit

[Pawan Gupta]

On Fri, Sep 02, 2022 at 12:35:13PM -0700, Jim Mattson wrote:
> On Fri, Sep 2, 2022 at 12:14 PM Pawan Gupta <pawan.kumar.gupta@intel.com> wrote:
> 
> > 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.
> 
> Gadgets abound, and there are tools to find them, if the attacker has
> the victim binary.

Agree.

> >  - Controlling register inputs to the gadget.
> 
> This is non-trivial, since kvm clears GPRs on VM-exit. However, an
> attacker can look for calls to kvm_read_register() or similar places
> where kvm loads elements of guest state. The instruction emulator and
> local APIC emulation both seem like promising targets.

Those "elements of guest state" needs to also survive till the desired
indirect-branch site, it could be possible.

> >  - Injecting the disclosure gadget in the predictors before it can be
> >    transiently executed.
> 
> IIUC, the gadget has to already be an indirect branch target that can
> be exercised by some guest action (e.g. writing to a specific x2APIC
> MSR). Is that correct?

That is correct.

> >  - Finding an appropriate indirect-branch site after VM-exit, and before
> >    BHB is overwritten.
> 
> Is it the case that the RIP of the victim indirect branch has to alias
> to the RIP of the "training branch" above in the predictors?

No, its due to collision in history based predictors that account for
branch history + RIP.

> Presumably, guest influence diminishes after every branch, even before
> the BHB is completely overwritten.

That is true, with every taken-branch the guest control diminishes.

Thanks,
Pawan