Re: [PATCH v3 21/35] x86/bugs: Determine relevant vulnerabilities based on attack vector controls.

Pawan Gupta
2025-01-09T03:43:14Z

On Wed, Jan 08, 2025 at 02:25:01PM -0600, David Kaplan wrote:
> The function should_mitigate_vuln() defines which vulnerabilities should
> be mitigated based on the selected attack vector controls. The
> selections here are based on the individual characteristics of each
> vulnerability.
>
> Signed-off-by: David Kaplan <david.kaplan@amd.com>
> ---
> arch/x86/kernel/cpu/bugs.c | 69 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 88eba8e4c7fb..175dbbf9b06e 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -347,6 +347,75 @@ static void x86_amd_ssb_disable(void)
> wrmsrl(MSR_AMD64_LS_CFG, msrval);
> }
>
> +/*
> + * Returns true if vulnerability should be mitigated based on the
> + * selected attack vector controls
> + *
> + * See Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
> + */
> +static bool __init should_mitigate_vuln(unsigned int bug)
> +{
> + switch (bug) {
> + /*
> + * The only spectre_v1 mitigations in the kernel are related to
> + * SWAPGS protection on kernel entry. Therefore, protection is
> + * only required for the user->kernel attack vector.
> + */
> + case X86_BUG_SPECTRE_V1:
> + return cpu_mitigate_attack_vector(CPU_MITIGATE_USER_KERNEL);
> +
> + /*
> + * Both spectre_v2 and srso may allow user->kernel or
> + * guest->host attacks through branch predictor manipulation.
> + */
> + case X86_BUG_SPECTRE_V2:
> + case X86_BUG_SRSO:
> + return cpu_mitigate_attack_vector(CPU_MITIGATE_USER_KERNEL) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_HOST);
> +
> + /*
> + * spectre_v2_user refers to user->user or guest->guest branch
> + * predictor attacks only. Other indirect branch predictor attacks
> + * are covered by the spectre_v2 vulnerability.
> + */
> + case X86_BUG_SPECTRE_V2_USER:
> + return cpu_mitigate_attack_vector(CPU_MITIGATE_USER_USER) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_GUEST);
> +
> + /* L1TF is only possible as a guest->host attack */
> + case X86_BUG_L1TF:
> + return cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_HOST);
> +
> + /*
> + * All the vulnerabilities below allow potentially leaking data
> + * across address spaces. Therefore, mitigation is required for
> + * any of these 4 attack vectors.
> + */
> + case X86_BUG_MDS:
> + case X86_BUG_TAA:
> + case X86_BUG_MMIO_STALE_DATA:
> + case X86_BUG_RFDS:
> + case X86_BUG_SRBDS:
> + return cpu_mitigate_attack_vector(CPU_MITIGATE_USER_KERNEL) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_HOST) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_USER_USER) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_GUEST);
> + /*
> + * GDS can potentially leak data across address spaces and
> + * threads. Mitigation is required under all attack vectors.
> + */
> + case X86_BUG_GDS:
> + return cpu_mitigate_attack_vector(CPU_MITIGATE_USER_KERNEL) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_HOST) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_USER_USER) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_GUEST_GUEST) ||
> + cpu_mitigate_attack_vector(CPU_MITIGATE_CROSS_THREAD);
> + default:
> + return false;

It is missing the case X86_BUG_RETBLEED. should_mitigate_vuln() will always
return false for retbleed.

I am wondering if this function should return true in the default case. So
that in future if someone misses to add a case for a new bug, it will still
be mitigated.