On Thu, Jul 04, 2024 at 03:05:05PM +0200, Peter Zijlstra wrote: > And how are we to ascertain the software using these hooks is deemed > secure? What security risks are there for the kernel if a malicious > userspace process asks for these rights? > > The kernel must assume malice on the part of userspace. Thanks, Peter. I don't believe there are any additional security risks for the kernel itself being introduced here. The kernel is only responsible for copying to and from userspace registers for the hypercall, and executing the TDCALL. A similar approach already exists for AMD SEV (see vc_handle_vmmcall), which does not restrict VMMCALL in the way that TDX restricts VMCALL. In the case of a malicious binary running in a TDX VM, if it wants to communicate with the untrusted hypervisor or other software outside of the TD, there are several existing mechanisms it could use, not just a VMCALL. I guess the point here is that if the userspace program is malicious, is anything gained by restricting VMCALL? This patchset really only handles the case where a trusted guest wants to limit access to VMCALL to binaries that self identify as hardened against potential host attacks.
