linux-kernel - Re: [RFC v2-fix-v5 1/1] x86: Skip WBINVD instruction for VM guest

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]

Message-ID: <7c06b567-9a65-8c7c-6046-3dcb32d4bb15@intel.com>
Date:   Wed, 9 Jun 2021 14:03:15 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Dan Williams <dan.j.williams@...el.com>
Cc:     Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix-v5 1/1] x86: Skip WBINVD instruction for VM guest

This changelog lacks both clear problem statements and a clear solution
implemented within the patch.

Here's a proposed changelog.  It clearly spells out the two problems
caused by WBINVD within a guest, and the proposed solution which fixes
those two problems.

Is this missing anything?

--

VM guests that support ACPI use standard ACPI mechanisms to signal sleep
state entry to the host.  To ACPI, reboot is simply another sleep state.

ACPI specifies that the platform preserve memory contents over (some)
sleep states.  It does not specify any requirements for data
preservation in CPU caches.  The ACPI specification mandates the use of
WBINVD to flush the contents of the CPU caches to memory before entering
specific sleep states, thus ensuring data in caches can survive sleep
state transitions.e

Unlike when entering sleep states bare metal, no actions within a guest
can cause data in processor caches to be lost.  That makes these WBINVD
invocations harmless but superfluous within a guest. (<--- problem #1)

In TDX guests, these WBINVD operations cause #VE exceptions.  For debug,
it would be ideal for the #VE handler to be able to WARN() when an
unexpected WBINVD occurs. (<--- problem #2)

Avoid WBINVD for all ACPI cache-flushing operations which occur while
running under a hypervisor, which includes TDX guests.  This both avoids
TDX warnings and optimizes away superfluous WBINVD invocations. (<----
solution)