linux-kernel - Re: [PATCH v10 11/11] x86/tdx: Handle CPUID via #VE

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:   Thu, 14 Oct 2021 06:25:58 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, Paolo Bonzini <pbonzini@...hat.com>,
        David Hildenbrand <david@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Juergen Gross <jgross@...e.com>, Deep Shah <sdeep@...are.com>,
        VMware Inc <pv-drivers@...are.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>
Cc:     Peter H Anvin <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 11/11] x86/tdx: Handle CPUID via #VE

On 10/14/21 5:01 AM, Thomas Gleixner wrote:
>> The TDX module specification [1], section titled "CPUID Virtualization"
>> talks about a few more classes of CPUID handling. But, for the purposes
>> of this patch, the "handled transparently" CPUID leaves are all lumped
>> together because the guest handling is the same.
> What means 'for the purposes of this patch'? And I have no idea what's
> lumped together means either.

The TDX spec talks about a several classes of CPUID bit fields.  These
matter in terms of trust because some of the bits can be supplied by the
VMM.  The original changelog here tried to draw a distinction between
bits which can be supplied by the VMM ("as configured" in the spec) and
those that come directly from the hardware ("native" in the spec).

"Lumped together" means that although these cases are differentiated in
the spec, their differences are immaterial for the purposes of this patch.

I think I wrote this.  I think I was trying to write it at someone who
might be puzzling over the TDX spec and its table of CPUID leaves
wondering why the #VE handler doesn't have cases for lots of the classes
called out in the spec.

> #VE is either raised on CPUID leaf/sub-leaf combinations which are not
> part of the CPUID virtualization table or on request of the guest for
> all CPUID invocations (either Ring0 or Ring3 or both).

Yes.  This changelog should also include a note about the unconditional
#VE for all CPUID executions feature, noting that it is expected to be
disabled for ring0.

> So this patch implements the #VE handling for EXIT_REASON_CPUID by
> handing it through to the hypercall, which in turn lets the TDX module
> handle it by invoking the host VMM.
> 
> So unless the guest requested #VE on all CPUID invocations it won't see
> a #VE for the transparent leaf/sub-leaf combinations. #VE is raised
> for the VMM handled ones which goes through the hypercall, right?

Yep, that's a pretty succinct way to put it.