le to only
hypercalls expected from the kernel.
Signed-off-by: Tim Merrifield
---
arch/x86/kernel/cpu/vmware.c | 51
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 00189cd
Add a new process-level prctl option to enable/disable user-level
hypercalls when running in a confidential VM. Add support for
checking this flag on VMCALL #VE for TDX and transfer control to
a hypervisor vendor-specific handler.
Signed-off-by: Tim Merrifield
---
arch/x86/coco/tdx/tdx.c
h 2: We now zero tdx_module_args to prevent data leakage to the VMM,
pointed out by Kirill.
Tim Merrifield (2):
Add prctl to allow userlevel TDX hypercalls
x86/vmware: VMware support for TDX userspace hypercalls
arch/x86/coco/tdx/tdx.c | 23 ++
arch/x86/include/asm/mm
Thanks for the review, Kirill.
On Mon, Jul 08, 2024 at 03:19:54PM +0300, Kirill A . Shutemov wrote:
> Hm. Per-thread flag is odd. I think it should be per-process.
This is the only point I might need some clarification on. I agree
there doesn't seem to be much value in allowing per-thread contr
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 u
Thanks for the response, Dave.
On Wed, Jul 03, 2024 at 05:18:22PM -0700, Dave Hansen wrote:
>
> Could we please be frank and transparent about what you actually want
> here and how you expect this mechanism to be used?
>
Sorry for being unclear. open-vm-tools is currently broken on TDX and
the
le to only
hypercalls expected from the kernel.
Signed-off-by: Tim Merrifield
---
arch/x86/kernel/cpu/vmware.c | 51
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 00189cd
Add a new prctl option to enable/disable user-level hypercalls when
running in a confidential VM. Add support for checking this flag on
VMCALL #VE for TDX and transfer control to a hypervisor
vendor-specific handler.
Signed-off-by: Tim Merrifield
---
arch/x86/coco/tdx/tdx.c| 18
sev_es_hcall_prepare/sev_es_hcall_finish). The flag has no effect on
non-TDX VMs. Other confidential computing technologies could use this flag
to provide limited access to user-level hypercalls.
Tim Merrifield (2):
x86/tdx: Add prctl to allow userlevel TDX hypercalls
x86/vmware: VMware support for TDX userspace
9 matches
Mail list logo