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

[Vitaly Kuznetsov]

Waiman Long <longman@xxxxxxxxxx> writes:

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

Makes sense. Or, alternatively, we can output 'unneeded' in both cases
to make things explicit and  to distinguish it from the current state of
IBPB where missing means 'unsupported by hardware'.

-- 
Vitaly