linux-kernel - Re: [RFC v2 16/32] x86/tdx: Handle MWAIT, MONITOR and WBINVD

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: <22d56f70-c69c-b3d2-51d6-962abdbc2882@intel.com>
Date:   Tue, 11 May 2021 07:08:56 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        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 Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 16/32] x86/tdx: Handle MWAIT, MONITOR and WBINVD

On 5/10/21 6:23 PM, Dan Williams wrote:
>> To prevent TD guest from using MWAIT/MONITOR instructions,
>> support for these instructions are already disabled by TDX
>> module (SEAM). So CPUID flags for these instructions should
>> be in disabled state.
> Why does this not result in a #UD if the instruction is disabled by
> SEAM? How is it possible to execute a disabled instruction (one
> precluded by CPUID) to the point where it triggers #VE instead of #UD?

This is actually a vestige of VMX.  It's quite possible toady to have a
feature which isn't enumerated in CPUID which still exists and "works"
in the silicon.  There are all kinds of pitfalls to doing this, but
folks evidently do it in public clouds all the time.

The CPUID virtualization basically just traps into the hypervisor and
lets the hypervisor set whatever register values it wants to appear when
CPUID "returns".

But, the controls for what instructions generate #UD are actually quite
separate and unrelated to CPUID itself.