On Thu, Nov 12, 2020 at 11:15:34AM +1100, Anand K Mistry wrote:
> commit 1978b3a53a74e3230cd46932b149c6e62e832e9a upstream.
>
> On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
> STIBP is set to on and
>
> spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
>
> At the same time, IBPB can be set to conditional.
>
> However, this leads to the case where it's impossible to turn on IBPB
> for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
>
> spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
>
> condition leads to a return before the task flag is set. Similarly,
> ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
> conditional.
>
> More generally, the following cases are possible:
>
> 1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
> 2. STIBP = on && IBPB = conditional for AMD CPUs with
> X86_FEATURE_AMD_STIBP_ALWAYS_ON
>
> The first case functions correctly today, but only because
> spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
>
> At a high level, this change does one thing. If either STIBP or IBPB
> is set to conditional, allow the prctl to change the task flag.
> Also, reflect that capability when querying the state. This isn't
> perfect since it doesn't take into account if only STIBP or IBPB is
> unconditionally on. But it allows the conditional feature to work as
> expected, without affecting the unconditional one.
>
> [ bp: Massage commit message and comment; space out statements for
> better readability. ]
>
> Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
> Signed-off-by: Anand K Mistry <amistry@xxxxxxxxxx>
> Signed-off-by: Borislav Petkov <bp@xxxxxxx>
> Acked-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Acked-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
> Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
>
> Conflicts:
> arch/x86/kernel/cpu/bugs.c
>
> Superfluous newline which was removed in upstream commit a5ce9f2bb665
>
> ---
> The one conflict is a newline in a comment which was removed in upstream
> commit a5ce9f2bb665, but was not merged into the stable trees.
>
> This patch applies cleanly on the stable trees 5.4, 4.19, 4.14, 4.9, and
> 4.4, which are affected by this bug.
Now queued up, thanks.
greg k-h
