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:
- STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
- 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@google.com Signed-off-by: Borislav Petkov bp@suse.de Acked-by: Thomas Gleixner tglx@linutronix.de Acked-by: Tom Lendacky thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4...
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