linux-kernel - [patch 0/2] x86: Prevent Split-Lock-Detection wreckage on VMX hypervisors

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-next>] [day] [month] [year] [list]

Date:   Thu, 02 Apr 2020 14:32:58 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     x86@...nel.org, "Kenneth R. Crudup" <kenny@...ix.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jessica Yu <jeyu@...nel.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Nadav Amit <namit@...are.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: [patch 0/2] x86: Prevent Split-Lock-Detection wreckage on VMX hypervisors

Kenneth reported that a VMWare guest crashes in the VMWare BIOS due to a
Split-Lock induced #AC which is injected by the VMWare hypervisor into the
guest.

While this is a good thing in principle, it's not really practical.
That means that Split-Lock-Detection has to be disabled when any
unprepared VMX hypervisor is loaded.

As hypervisor modules are not really identifiable, the only safe solution
we came up with is to scan the module text at load time for a VMLAUNCH
instruction. If VMLAUNCH is found then Split-Lock-Detection is disabled on
the host to prevent the above. If the hypervisor has at least minimal
handling code, the module can tell the kernel by adding MOD_INFO(sld_safe,
"Y") which disables the text scan.

For KVM it's simple enough to handle it at least at the basic level by
checking guest CR0.AM and EFLAGS.AC state and a trivial host side
handler which depending on the SLD mode handles it gracefully or tells
the VMX handler to deliver the #AC to user space which then can crash
and burn itself.

As Peter and myself don't have access to a SLD enabled machine, the
KVM/VMX part is untested. The module scan part works.

Alternatively we can obviously revert SLD, but that does not make the
problem vs. out of tree hypervisors go away magically. So we can just
get over it now.

Thanks,

	tglx