Re: [PATCHv4 10/30] x86/tdx: Handle CPUID via #VE

Kirill A. Shutemov
2022-02-28T23:31:18Z

On Mon, Feb 28, 2022 at 03:05:26PM -0800, Dave Hansen wrote:
> On 2/28/22 14:53, Kirill A. Shutemov wrote:
> > 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.
>
> Seems sane to me. This closes off basically any ability for the VMM to
> confuse the guest with CPUID values except for the ones that *must* by
> hypervisor-controlled.
>
> Does this, in practice, keep TDX guests from detecting any features that
> it supports today?

I scanned through the list of CPUID that probed via #VE during the boot
and they are related to cache/TLB hierarchy enumeration, thermal and
topology. Without cache/TLB enumeration we may miss some optimization.
Topology can be problematic, we may miss ability to communicate the
configuration, I donno.

Shouldn't be a show-stopper.

--
Kirill A. Shutemov