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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.12.2024 20:34, 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@xxxxxxxxxx>
> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> 
> I cannot say anything more about the SRSO_U/S_NO vs SRSO_MSR_FIX interactions
> in public.  The safety for PV guests depends on details not covered in the
> whitepaper.
> 
> v3:
>  * Rewrite commit message and comments quite a lot.
> 
> This patch was originally for-4.19.  Zen5 CPUs are now in the world and Xen is
> unsafe on them without this patch.
> 
> I technically have enough tags to commit it, and it's long overdue, but I
> think it would be wise to see if the new wording is clearer to others.

It is to me; thanks for making these adjustments.

As to said implementation detail: I suppose we can only hope that yet newer
implementations won't break this.

Jan