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: <33874bf0-c115-4185-85ef-684794de3c8e@intel.com>
Date: Wed, 3 Jul 2024 17:18:22 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Tim Merrifield <tim.merrifield@...adcom.com>,
 "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.amakhalov@...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 7/3/24 16:35, Tim Merrifield wrote:
> VMCALL and VMMCALL instructions are used by x86 guests to request services
> from the host VMM. Both VMCALL and VMMCALL are not restricted to CPL 0.
> This allows userspace software like open-vm-tools to communicate directly
> with the VMM.

Could we please be frank and transparent about what you actually want
here and how you expect this mechanism to be used?

...
> This patchset introduces a new x86 process control flag to address this
> concern. By setting the TIF_COCO_USER_HCALL thread information flag, the
> process opts in to user-level hypercalls.

The process, and anything it fork()s or execve()s, right?

This inheritance model seems more suited to wrapping a tiny helper app
around an existing binary, a la:

	prctl(ARCH_SET_COCO_USER_HCALL);
	execve("/existing/binary/that/i/surely/did/not/audit", ...);

... as opposed to something that you set in new versions of
open-vm-tools after an extensive audit and a bug fixing campaign to
clean up everything that the audit found.