linux-kernel - Re: [PATCH v9 05/18] x86/virt/tdx: Add SEAMCALL infrastructure

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: <37d5736e-93b1-aed1-c21c-07fe1044f2d0@intel.com>
Date:   Mon, 13 Feb 2023 14:39:12 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Kai Huang <kai.huang@...el.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Cc:     linux-mm@...ck.org, peterz@...radead.org, tglx@...utronix.de,
        seanjc@...gle.com, pbonzini@...hat.com, dan.j.williams@...el.com,
        rafael.j.wysocki@...el.com, kirill.shutemov@...ux.intel.com,
        ying.huang@...el.com, reinette.chatre@...el.com,
        len.brown@...el.com, tony.luck@...el.com, ak@...ux.intel.com,
        isaku.yamahata@...el.com, chao.gao@...el.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com, david@...hat.com,
        bagasdotme@...il.com, sagis@...gle.com, imammedo@...hat.com
Subject: Re: [PATCH v9 05/18] x86/virt/tdx: Add SEAMCALL infrastructure

On 2/13/23 03:59, Kai Huang wrote:
> SEAMCALL instruction causes #GP when TDX isn't BIOS enabled, and #UD
> when CPU is not in VMX operation.  The current TDX_MODULE_CALL macro
> doesn't handle any of them.  There's no way to check whether the CPU is
> in VMX operation or not.

Really?  ... *REALLY*?

Like, there's no possible way for the kernel to record whether it has
executed VMXON or not?

I think what you're saying here is that there's no architecturally
visible flag that tells you whether in spot #1 or #2 in the following code:

static int kvm_cpu_vmxon(u64 vmxon_pointer)
{
        u64 msr;

        cr4_set_bits(X86_CR4_VMXE);
// spot #1
        asm_volatile_goto("1: vmxon %[vmxon_pointer]\n\t"
                          _ASM_EXTABLE(1b, %l[fault])
                          : : [vmxon_pointer] "m"(vmxon_pointer)
                          : : fault);
// spot #2

That's _maybe_ technically correct (I don't know enough about VMX
enabling to tell you).  But, what I *DO* know is that it's nonsense to
say that it's impossible in the *kernel* to tell whether we're on a CPU
that's successfully executed VMXON or not.

kvm_cpu_vmxon() has two paths through it:

  1. Successfully executes VMXON and leaves with X86_CR4_VMXE=1
  2. Fails VMXON and leaves with X86_CR4_VMXE=0

Guess what?  CR4 is rather architecturally visible.  From what I can
tell, it's *ENTIRELY* plausible to assume that X86_CR4_VMXE==1 means
that VMXON has been done.  Even if that's wrong, it's only a cpumask and
a cpumask_set() away from becoming plausible.  Like so:

static int kvm_cpu_vmxon(u64 vmxon_pointer)
{
        u64 msr;

        cr4_set_bits(X86_CR4_VMXE);

        asm_volatile_goto("1: vmxon %[vmxon_pointer]\n\t"
                          _ASM_EXTABLE(1b, %l[fault])
                          : : [vmxon_pointer] "m"(vmxon_pointer)
                          : : fault);
	// set cpumask bit here
        return 0;

fault:
	// clear cpu bit here
        cr4_clear_bits(X86_CR4_VMXE);

        return -EFAULT;
}

How many design decisions down the line in this series were predicated
on the idea that:

	There's no way to check whether the CPU is
	in VMX operation or not.

?