Re: [PATCH 12/22] x86/srso: Remove redundant X86_FEATURE_ENTRY_IBPB check

[Borislav Petkov]

On Sun, Aug 20, 2023 at 06:19:09PM -0700, Josh Poimboeuf wrote:
> The X86_FEATURE_ENTRY_IBPB check is redundant here due to the above
> RETBLEED_MITIGATION_IBPB check.  RETBLEED_MITIGATION_IBPB already
> implies X86_FEATURE_ENTRY_IBPB.  So if we got here and 'has_microcode'
> is true, it means X86_FEATURE_ENTRY_IBPB is not set.
> 
> Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> ---
>  arch/x86/kernel/cpu/bugs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index b27aeb86ed7a..aeddd5ce9f34 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -2475,7 +2475,7 @@ static void __init srso_select_mitigation(void)
>  
>  	case SRSO_CMD_IBPB_ON_VMEXIT:
>  		if (IS_ENABLED(CONFIG_CPU_SRSO)) {
> -			if (!boot_cpu_has(X86_FEATURE_ENTRY_IBPB) && has_microcode) {
> +			if (has_microcode) {
>  				setup_force_cpu_cap(X86_FEATURE_IBPB_ON_VMEXIT);
>  				srso_mitigation = SRSO_MITIGATION_IBPB_ON_VMEXIT;
>  			}

Well, frankly, I'd prefer to keep this check explicit as it is also
documenting the situation. And it is also protecting against future,
potential mistakes done while refactoring. And it is not such a complex
condition so that it stands in the way and makes the code too
unreadable, while removing it makes it a bit too subtle considering the
amazing maze we're in.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette