linux-kernel - Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 15 Apr 2024 10:17:06 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Alexandre Chartre <alexandre.chartre@...cle.com>,
 Chao Gao <chao.gao@...el.com>, Andrew Cooper <andrew.cooper3@...rix.com>
Cc: x86@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 daniel.sneddon@...ux.intel.com, pawan.kumar.gupta@...ux.intel.com,
 tglx@...utronix.de, konrad.wilk@...cle.com, peterz@...radead.org,
 gregkh@...uxfoundation.org, seanjc@...gle.com, dave.hansen@...ux.intel.com,
 nik.borisov@...e.com, kpsingh@...nel.org, longman@...hat.com, bp@...en8.de,
 pbonzini@...hat.com
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected
 by BHI

> +       /*
> +        * 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.