@@ -1401,16 +1401,69 @@ static void __init spectre_v2_select_mitigation(void)
14011401 pr_info ("%s\n" , spectre_v2_strings [mode ]);
14021402
14031403 /*
1404- * If spectre v2 protection has been enabled, unconditionally fill
1405- * RSB during a context switch; this protects against two independent
1406- * issues:
1404+ * If Spectre v2 protection has been enabled, fill the RSB during a
1405+ * context switch. In general there are two types of RSB attacks
1406+ * across context switches, for which the CALLs/RETs may be unbalanced.
14071407 *
1408- * - RSB underflow (and switch to BTB) on Skylake+
1409- * - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
1408+ * 1) RSB underflow
1409+ *
1410+ * Some Intel parts have "bottomless RSB". When the RSB is empty,
1411+ * speculated return targets may come from the branch predictor,
1412+ * which could have a user-poisoned BTB or BHB entry.
1413+ *
1414+ * AMD has it even worse: *all* returns are speculated from the BTB,
1415+ * regardless of the state of the RSB.
1416+ *
1417+ * When IBRS or eIBRS is enabled, the "user -> kernel" attack
1418+ * scenario is mitigated by the IBRS branch prediction isolation
1419+ * properties, so the RSB buffer filling wouldn't be necessary to
1420+ * protect against this type of attack.
1421+ *
1422+ * The "user -> user" attack scenario is mitigated by RSB filling.
1423+ *
1424+ * 2) Poisoned RSB entry
1425+ *
1426+ * If the 'next' in-kernel return stack is shorter than 'prev',
1427+ * 'next' could be tricked into speculating with a user-poisoned RSB
1428+ * entry.
1429+ *
1430+ * The "user -> kernel" attack scenario is mitigated by SMEP and
1431+ * eIBRS.
1432+ *
1433+ * The "user -> user" scenario, also known as SpectreBHB, requires
1434+ * RSB clearing.
1435+ *
1436+ * So to mitigate all cases, unconditionally fill RSB on context
1437+ * switches.
1438+ *
1439+ * FIXME: Is this pointless for retbleed-affected AMD?
14101440 */
14111441 setup_force_cpu_cap (X86_FEATURE_RSB_CTXSW );
14121442 pr_info ("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n" );
14131443
1444+ /*
1445+ * Similar to context switches, there are two types of RSB attacks
1446+ * after vmexit:
1447+ *
1448+ * 1) RSB underflow
1449+ *
1450+ * 2) Poisoned RSB entry
1451+ *
1452+ * When retpoline is enabled, both are mitigated by filling/clearing
1453+ * the RSB.
1454+ *
1455+ * When IBRS is enabled, while #1 would be mitigated by the IBRS branch
1456+ * prediction isolation protections, RSB still needs to be cleared
1457+ * because of #2. Note that SMEP provides no protection here, unlike
1458+ * user-space-poisoned RSB entries.
1459+ *
1460+ * eIBRS, on the other hand, has RSB-poisoning protections, so it
1461+ * doesn't need RSB clearing after vmexit.
1462+ */
1463+ if (boot_cpu_has (X86_FEATURE_RETPOLINE ) ||
1464+ boot_cpu_has (X86_FEATURE_KERNEL_IBRS ))
1465+ setup_force_cpu_cap (X86_FEATURE_RSB_VMEXIT );
1466+
14141467 /*
14151468 * Retpoline protects the kernel, but doesn't protect firmware. IBRS
14161469 * and Enhanced IBRS protect firmware too, so enable IBRS around
0 commit comments