On Mon, 2024-11-11 at 17:46 -0800, Josh Poimboeuf wrote:
> On Tue, Nov 12, 2024 at 12:29:28AM +0000, Andrew Cooper wrote:
> > This is my take. On AMD CPUs, there are two unrelated issues to
> > take
> > into account:
> >
> > 1) SRSO
> >
> > Affects anything which doesn't enumerate SRSO_NO, which is all
> > parts to
> > date including Zen5.
> >
> > SRSO ends up overflowing the RAS with arbitrary BTB targets, such
> > that a
> > subsequent genuine RET follows a prediction which never came from a
> > real
> > CALL instruction.
> >
> > Mitigations for SRSO are either safe-ret, or IBPB-on-entry. Parts
> > without IBPB_RET using IBPB-on-entry need to manually flush the
> > RAS.
> >
> > Importantly, SMEP does not protection you against SRSO across the
> > user->kernel boundary, because the bad RAS entries are arbitrary.
> > New
> > in Zen5 is the SRSO_U/S_NO bit which says this case can't occur any
> > more. So on Zen5, you can in principle get away without a RAS
> > flush on
> > entry.
>
> Updated to mention SRSO:
>
> /*
> * In general there are two types of RSB attacks:
> *
> * 1) RSB underflow ("Intel Retbleed")
> *
> * Some Intel parts have "bottomless RSB". When the RSB
> is empty,
> * speculated return targets may come from the branch
> predictor,
> * which could have a user-poisoned BTB or BHB entry.
> *
> * When IBRS or eIBRS is enabled, the "user -> kernel"
> attack is
> * mitigated by the IBRS branch prediction isolation
> properties, so
> * the RSB buffer filling wouldn't be necessary to
> protect against
> * this type of attack.
> *
> * The "user -> user" attack is mitigated by RSB filling
> on context
> * switch.
> *
> * The "guest -> host" attack is mitigated by IBRS or
> eIBRS.
> *
> * 2) Poisoned RSB entry
> *
> * If the 'next' in-kernel return stack is shorter than
> 'prev',
> * 'next' could be tricked into speculating with a user-
> poisoned RSB
> * entry. Poisoned RSB entries can also be created by
> Branch Type
> * Confusion ("AMD retbleed") or SRSO.
> *
> * The "user -> kernel" attack is mitigated by SMEP and
> eIBRS. AMD
> * without SRSO_NO also needs the SRSO mitigation.
> *
> * The "user -> user" attack, also known as SpectreBHB,
> requires RSB
> * clearing.
> *
> * The "guest -> host" attack is mitigated by either
> eIBRS (not
> * IBRS!) or RSB clearing on vmexit. Note that eIBRS
> * implementations with X86_BUG_EIBRS_PBRSB still need
> "lite" RSB
> * clearing which retires a single CALL before the first
> RET.
> */
Thanks, Josh and Andrew. This reads well to me. In the context of
ERAPS, I'll end up adding a couple more sentences there as well.
Amit
