Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 1 Mar 2022 01:53:36 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        luto@kernel.org, peterz@infradead.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com,
        tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
        thomas.lendacky@amd.com, brijesh.singh@amd.com, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4 10/30] x86/tdx: Handle CPUID via #VE
Message-ID: <20220228225336.k3lxk5qqm4vpaocv@black.fi.intel.com>
References: <20220224155630.52734-1-kirill.shutemov@linux.intel.com>
 <20220224155630.52734-11-kirill.shutemov@linux.intel.com>
 <51b6613d-eabd-941d-19b2-95b33ec27e99@intel.com>
 <20220227010733.abapkmyaroglcafl@black.fi.intel.com>
 <7a8c4e5e-c0ba-ee8e-a912-c71f89b4d4f2@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7a8c4e5e-c0ba-ee8e-a912-c71f89b4d4f2@intel.com>
Precedence: bulk

On Mon, Feb 28, 2022 at 08:41:38AM -0800, Dave Hansen wrote:
> > We realise that this is possible vector of attack and plan to implement
> > proper filtering. But it is beyon core enabling.
> > 
> >> Is this better than just returning 0's, for instance?
> > 
> > Plain 0 injection breaks the boot. More complicated solution is need.
> 
> OK, so we're leaving the kernel open to something that might be an
> attack vector: we know that we don't know how this might be bad.  It's a
> "known unknown"[1].

I looked deeper. The only CPUIDs that actually required are from the
hypervisor range (the range is reserved and never will be used by CPU, so
hypervisors adopt it for own use).

So this filtering makes kernel boot (I didn't test much beyond that).

	/*
	 * Only allow VMM to control range reserved for hypervisor
	 * communication.
	 *
	 * Return all-zeros for any CPUID outside the range.
	 */
	if (regs->ax < 0x40000000 || regs->ax > 0x4FFFFFFF) {
		regs->ax = regs->bx = regs->cx = regs->dx = 0;
		return true;
	}

We may tighten the range further (only few leafs from the range is
actually used during the boot), but this should be good enough for this
stage of enabling.

Comments?

-- 
 Kirill A. Shutemov