linux-kernel - Re: [PATCH] cpu/hotplug: Fix "SMT disabled by BIOS" detection for KVM

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:   Tue, 29 Jan 2019 14:37:35 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     x86@...nel.org
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Joe Mario <jmario@...hat.com>, Jiri Kosina <jikos@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>, kvm@...r.kernel.org,
        Igor Mammedov <imammedo@...hat.com>
Subject: Re: [PATCH] cpu/hotplug: Fix "SMT disabled by BIOS" detection for KVM

On Mon, Jan 28, 2019 at 10:52:56AM -0600, Josh Poimboeuf wrote:
> With the following commit:
> 
>   73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
> 
> ... the hotplug code attempted to detect when SMT was disabled by BIOS,
> in which case it reported SMT as permanently disabled.  However, that
> code broke a virt hotplug scenario, where the guest is booted with only
> primary CPU threads, and a sibling is brought online later.
> 
> The problem is that there doesn't seem to be a way to reliably
> distinguish between the HW "SMT disabled by BIOS" case and the virt
> "sibling not yet brought online" case.  So the above-mentioned commit
> was a bit misguided, as it permanently disabled SMT for both cases,
> preventing future virt sibling hotplugs.
> 
> Going back and reviewing the original problems which were attempted to
> be solved by that commit, when SMT was disabled in BIOS:
> 
>   1) /sys/devices/system/cpu/smt/control showed "on" instead of
>      "notsupported"; and
> 
>   2) vmx_vm_init() was incorrectly showing the L1TF_MSG_SMT warning.
> 
> I'd propose that we instead consider #1 above to not actually be a
> problem.  Because, at least in the virt case, it's possible that SMT
> wasn't disabled by BIOS and a sibling thread could be brought online
> later.  So it makes sense to just always default the smt control to "on"
> to allow for that possibility (assuming cpuid indicates that the CPU
> supports SMT).
> 
> The real problem is #2, which has a simple fix: change vmx_vm_init() to
> query the actual current SMT state -- i.e., whether any siblings are
> currently online -- instead of looking at the SMT "control" sysfs value.
> 
> So fix it by:
> 
>   a) reverting the original "fix" and its followup fix:
> 
>      73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
>      bc2d8d262cba ("cpu/hotplug: Fix SMT supported evaluation")
> 
>      and
> 
>   b) changing vmx_vm_init() to query the actual current SMT state --
>      instead of the sysfs control value -- to determine whether the L1TF
>      warning is needed.
> 
> Fixes: 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
> Reported-by: Igor Mammedov <imammedo@...hat.com>
> Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>

NACK - Need to export "sched_smt_present" so KVM can call
sched_smt_active().

-- 
Josh