linux-kernel - Re: [RFC v2-fix-v4 1/1] x86/tdx: Skip WBINVD instruction for TDX 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: <ec761262-2e32-cee0-ea3b-184086e7a202@intel.com>
Date:   Wed, 9 Jun 2021 07:12:43 -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-v4 1/1] x86/tdx: Skip WBINVD instruction for TDX
 guest

On 6/8/21 6:10 PM, Kuppuswamy Sathyanarayanan wrote:
> Since cache is always coherent in TDX guests, making wbinvd as
> noop should not cause any issues in above mentioned code path.
> The end-behavior is the same as KVM guest (treat as noops).

I don't see anything in the specs to back up such a broad statement.

For Secure-EPT, I see in the TDX "EAS" that "Ignore PAT" is "Set to 1".
 This, presumably along with the "TD VMCS Guest MSRs... IA32_PAT" being
set to 0x0007040600070406 (I didn't decode it, I'm just guessing),
ensures that guests using Secure-EPT have no architectural way of
creating non-coherent mappings using the guest x86 page tables.

That covers one of the memory types to which guests have access.

Guests can also access TD-shared memory.  Those mappings are controlled
by the VMM and not mapped by Secure-EPT.  This is the part that concerns
me and is not consistent with the statement above.  Is it
architecturally impossible for a VMM to create an non-coherent mapping
and expose it to a guest?  If it is impossible, please include citations
of the spec or the logic behind this so that a reader can understand,
just as I did above.

If it is possible to have non-coherent mappings in a guest, then please
remove the above statement.