Re: [PATCH RFC] x86/speculation: Clarify Spectre-v2 mitigation when STIBP/IBPB features are unsupported

[Waiman Long <longman@redhat.com>]

On 1/21/20 11:02 AM, Vitaly Kuznetsov wrote:
> When STIBP/IBPB features are not supported (no microcode update,
> AWS/Azure/... instances deliberately hiding SPEC_CTRL for performance
> reasons,...) /sys/devices/system/cpu/vulnerabilities/spectre_v2 looks like
>
>   Mitigation: Full generic retpoline, STIBP: disabled, RSB filling
>
> and this looks imperfect. In particular, STIBP is 'disabled' and 'IBPB'
> is not mentioned while both features are just not supported. Also, for
> STIBP the 'disabled' state (SPECTRE_V2_USER_NONE) can represent both
> the absence of hardware support and deliberate user's choice
> (spectre_v2_user=off)
>
> Make the following adjustments:
> - Output 'unsupported' for both STIBP/IBPB when there's no support in
>   hardware.
> - Output 'unneeded' for STIBP when SMT is disabled/missing (and this
>   switch_to_cond_stibp is off).

I support outputting "unsupported" when the microcode doesn't support
it. However, I am not sure if "unneeded" is really necessary or not.
STIBP is not needed when SMT is disabled or when Enhanced IBRS is
available and used. Your patch handles the first case, but not the
second. I think it may be easier to just leave it out in case it is not
needed.

Cheers,
Longman