Re: [PATCH v3] x86/spec-ctrl: Support for SRSO_U/S_NO and SRSO_MSR_FIX

["Roger Pau Monné" <roger.pau@citrix.com>]

On Fri, Dec 20, 2024 at 07:34:24PM +0000, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information.  These
> features exist on AMD Zen5 CPUs and are necessary for Xen to use.
> 
> The two features are in principle unrelated:
> 
>  * SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
>    User(CPL3) / Supervisor(CPL<3) boundary.  i.e. Xen don't need to use
>    IBPB-on-entry for PV64.  PV32 guests are explicitly unsupported for
>    speculative issues, and excluded from consideration for simplicity.
> 
>  * SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
>    available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
>    boundary.  i.e. Xen don't need to use IBPB-on-entry for HVM.
> 
> Extend ibpb_calculations() to account for these when calculating
> opt_ibpb_entry_{pv,hvm} defaults.  Add a `bp-spec-reduce=<bool>` option to
> control the use of BP_SPEC_REDUCE, with it active by default.
> 
> Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
> amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
> once.
> 
> Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
> to skip SRSO mitigations too:
> 
>  * This is trivial for HVM guests.  It is also is accurate for PV32 guests
>    too, but we have already excluded them from consideration, and do so again
>    here to simplify the policy logic.
> 
>  * As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
>    However, after discussing with AMD, an implementation detail of having
>    BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
>    property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
>    guests when the BP_SPEC_REDUCE precondition is met.
> 
> Finally, fix a typo in the SRSO_NO's comment.
> 
> [1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

FTAOD, my RB tag stands given the changes in v3.

Thanks, Roger.