On 4/15/24 19:17, Dave Hansen wrote:
+ /* + * The following Intel CPUs are affected by BHI, but they don't have + * the eIBRS feature. In that case, the default Spectre v2 mitigations + * are enough to also mitigate BHI. We mark these CPUs with NO_BHI so + * that X86_BUG_BHI doesn't get set and no extra BHI mitigation is + * enabled. + * + * This avoids guest VMs from enabling extra BHI mitigation when this + * is not needed. For guest, X86_BUG_BHI is never set for CPUs which + * don't have the eIBRS feature. But this doesn't happen in guest VMs + * as the virtualization can hide the eIBRS feature. + */ + VULNWL_INTEL(IVYBRIDGE_X, NO_BHI), + VULNWL_INTEL(HASWELL_X, NO_BHI), + VULNWL_INTEL(BROADWELL_X, NO_BHI), + VULNWL_INTEL(SKYLAKE_X, NO_BHI), + VULNWL_INTEL(SKYLAKE_X, NO_BHI),Isn't this at odds with the existing comment? /* When virtualized, eIBRS could be hidden, assume vulnerable */ Because it seems now that we've got two relatively conflicting pieces of vulnerability information when running under a hypervisor.
It's not at odd, it's an additional information. The comment covers the general case. When running under a hypervisor then the kernel can't rely on CPU features to find if the server has eIBRS or not, because the virtualization can be hiding eIBRS. And that's the problem because the kernel might enable BHI mitigation while it's not needed. For example on Skylake: on the host, the kernel won't see eIBRS so it won't set X86_BUG_BHI. But in a guest on the same platform, the kernel will set X86_BUG_BHI because it doesn't know if the server doesn't effectively have eIBRS or if eIBRS is hidden by virtualization. With the patch, the kernel can know if the CPU it is running on (e.g. Skylake) needs extra BHI mitigation or not. Then it can safely not enable BHI mitigation no matter if it is running on host or in guest. alex.
