linux-kernel - Re: [PATCHv4 10/30] 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]

Message-ID: <20220228225336.k3lxk5qqm4vpaocv@black.fi.intel.com>
Date:   Tue, 1 Mar 2022 01:53:36 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        luto@...nel.org, peterz@...radead.org,
        sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
        ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
        hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
        joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
        pbonzini@...hat.com, sdeep@...are.com, seanjc@...gle.com,
        tony.luck@...el.com, vkuznets@...hat.com, wanpengli@...cent.com,
        thomas.lendacky@....com, brijesh.singh@....com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 10/30] x86/tdx: Handle CPUID via #VE

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