linux-kernel - Re: [RFC v2-fix-v2 1/1] x86/tdx: Wire up KVM hypercalls

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <97588756-5c12-2913-05a7-938eb7a510c8@intel.com>
Date:   Tue, 18 May 2021 16:29:25 -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>
Cc:     Tony Luck <tony.luck@...el.com>, Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix-v2 1/1] x86/tdx: Wire up KVM hypercalls

On 5/18/21 2:19 PM, Kuppuswamy Sathyanarayanan wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
> 
> KVM hypercalls use the "vmcall" or "vmmcall" instructions.
> Although the ABI is similar, those instructions no longer
> function for TDX guests. Make vendor-specific TDVMCALLs
> instead of VMCALL. This enables TDX guests to run with KVM
> acting as the hypervisor. TDX guests running under other
> hypervisors will continue to use those hypervisor's
> hypercalls.

Well, I screwed this up when I typed it too, but it is:

	TDX guests running under other hypervisors will continue
	to use those hypervisors' hypercalls.

I hate how that reads, but oh well.

> Since KVM hypercall functions can be included and called
> from kernel modules, export tdx_kvm_hypercall*() functions
> to avoid symbol errors

No, you're not avoiding errors, you're exporting the symbol so it can be
*USED*.  The error comes from it not being exported.

It also helps to be specific here:  Export tdx_kvm_hypercall*() to make
the symbols visible to kvm.ko.

> [Isaku Yamahata: proposed KVM VENDOR string]
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Reviewed-by: Andi Kleen <ak@...ux.intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>

Reviewed-by: Dave Hansen <dave.hansen@...el.com>

Also, FWIW, if you did this in the header:

+static inline long tdx_kvm_hypercall0(unsigned int nr)
+{
+	return tdx_kvm_hypercall(nr, 0, 0, 0, 0);
+}

You could get away with just exporting tdx_kvm_hypercall() instead of 4
symbols.  The rest of the code would look the same.