Messages in this thread Patch in this message | | | Date | Sun, 27 Feb 2022 04:07:33 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv4 10/30] x86/tdx: Handle CPUID via #VE |
| |
On Thu, Feb 24, 2022 at 11:04:04AM -0800, Dave Hansen wrote: > On 2/24/22 07:56, Kirill A. Shutemov wrote: > > static bool virt_exception_user(struct pt_regs *regs, struct ve_info *ve) > > { > > - pr_warn("Unexpected #VE: %lld\n", ve->exit_reason); > > - return false; > > + switch (ve->exit_reason) { > > + case EXIT_REASON_CPUID: > > + return handle_cpuid(regs); > > + default: > > + pr_warn("Unexpected #VE: %lld\n", ve->exit_reason); > > + return false; > > + } > > } > > What does this mean for userspace? What kinds of things are we ceding > to the (untrusted) VMM to supply to userspace?
Here's what I see called from userspace. CPUID(AX=0x2) CPUID(AX=0xb, CX=0x0) CPUID(AX=0xb, CX=0x1) CPUID(AX=0x40000000, CX=0xfffaba17) CPUID(AX=0x80000007, CX=0x121)
> > /* Handle the kernel #VE */ > > @@ -200,6 +235,8 @@ static bool virt_exception_kernel(struct pt_regs *regs, struct ve_info *ve) > > return read_msr(regs); > > case EXIT_REASON_MSR_WRITE: > > return write_msr(regs); > > + case EXIT_REASON_CPUID: > > + return handle_cpuid(regs); > > default: > > pr_warn("Unexpected #VE: %lld\n", ve->exit_reason); > > return false; > What kinds of random CPUID uses in the kernel at runtime need this > handling?
CPUID(AX=0x2) CPUID(AX=0x6, CX=0x0) CPUID(AX=0xb, CX=0x0) CPUID(AX=0xb, CX=0x1) CPUID(AX=0xb, CX=0x2) CPUID(AX=0xf, CX=0x0) CPUID(AX=0xf, CX=0x1) CPUID(AX=0x10, CX=0x0) CPUID(AX=0x10, CX=0x1) CPUID(AX=0x10, CX=0x2) CPUID(AX=0x10, CX=0x3) CPUID(AX=0x16, CX=0x0) CPUID(AX=0x1f, CX=0x0) CPUID(AX=0x40000000, CX=0x0) CPUID(AX=0x40000000, CX=0xfffaba17) CPUID(AX=0x40000001, CX=0x0) CPUID(AX=0x80000002, CX=0x0) CPUID(AX=0x80000003, CX=0x0) CPUID(AX=0x80000004, CX=0x0) CPUID(AX=0x80000007, CX=0x0) CPUID(AX=0x80000007, CX=0x121)
> Is it really OK that we let the VMM inject arbitrary CPUID > values into random CPUID uses in the kernel... silently?
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.
-- Kirill A. Shutemov
| |