linux-kernel - Re: [PATCH 0/2] Support userspace hypercalls for TDX

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: <20240705185529.GA16769@prme-hs2-i1009>
Date: Fri, 5 Jul 2024 11:55:39 -0700
From: Tim Merrifield <tim.merrifield@...adcom.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>,
	Xin Li <xin3.li@...el.com>, Ard Biesheuvel <ardb@...nel.org>,
	Kai Huang <kai.huang@...el.com>,
	Kevin Loughlin <kevinloughlin@...gle.com>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Kees Cook <kees@...nel.org>, Mike Rapoport <rppt@...nel.org>,
	Brian Gerst <brgerst@...il.com>, linux-coco@...ts.linux.dev,
	linux-kernel@...r.kernel.org, Ajay Kaher <ajay.kaher@...adcom.com>,
	Alexey Makhalov <alexey.makhalov@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	virtualization@...ts.linux.dev, alex.james@...adcom.com,
	doug.covelli@...adcom.com, jeffrey.sheldon@...adcom.com
Subject: Re: [PATCH 0/2] Support userspace hypercalls for TDX

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.