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: <ay724yrnkvsuqjffsedi663iharreuu574nzc4v7fc5mqbwdyx@6ffxkqo3x5rv>
Date: Wed, 10 Apr 2024 15:49:36 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Dave Hansen <dave.hansen@...el.com>, 
	Rick P Edgecombe <rick.p.edgecombe@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Kai Huang <kai.huang@...el.com>, 
	Isaku Yamahata <isaku.yamahata@...el.com>, "x86@...nel.org" <x86@...nel.org>, 
	Tina Zhang <tina.zhang@...el.com>, Hang Yuan <hang.yuan@...el.com>, Bo2 Chen <chen.bo@...el.com>, 
	"sagis@...gle.com" <sagis@...gle.com>, "isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, 
	Erdem Aktas <erdemaktas@...gle.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>
Subject: Re: [PATCH v19 007/130] x86/virt/tdx: Export SEAMCALL functions

On Fri, Mar 15, 2024 at 09:33:20AM -0700, Sean Christopherson wrote:
> So my feedback is to not worry about the exports, and instead focus on figuring
> out a way to make the generated code less bloated and easier to read/debug.

I think it was mistake trying to centralize TDCALL/SEAMCALL calls into
few megawrappers. I think we can get better results by shifting leaf
function wrappers into assembly.

We are going to have more assembly, but it should produce better result.
Adding macros can help to write such wrapper and minimizer boilerplate.

Below is an example of how it can look like. It's not complete. I only
converted TDCALLs, but TDVMCALLs or SEAMCALLs. TDVMCALLs are going to be
more complex.

Any opinions? Is it something worth investing more time?

set offset_rcx,	TDX_MODULE_rcx
set offset_rdx,	TDX_MODULE_rdx
set offset_r8,		TDX_MODULE_r8
set offset_r9,		TDX_MODULE_r9
set offset_r10,	TDX_MODULE_r10
set offset_r11,	TDX_MODULE_r11

macro save_output struct_reg regs:vararg
irp reg,\regs
	movq	%\reg, offset_\reg(%\struct_reg)
endr
endm

macro tdcall leaf
	movq	\leaf, %rax
	.byte	0x66,0x0f,0x01,0xcc
endm

macro tdcall_or_panic leaf
	tdcall	\leaf
	testq	%rax, %rax
	jnz	.Lpanic
endm

SYM_FUNC_START(tdg_vm_rd)
	FRAME_BEGIN

	xorl	%ecx, %ecx
	movq	%rdi, %rdx

	tdcall_or_panic $TDG_VM_RD

	movq	%r8, %rax

	RET
	FRAME_END
SYM_FUNC_END(tdg_vm_rd)

SYM_FUNC_START(tdg_vm_wr)
	FRAME_BEGIN

	xorl	%ecx, %ecx
	movq	%rsi, %r8
	movq	%rdx, %r9
	movq	%rdi, %rdx

	tdcall_or_panic $TDG_VM_WR

	/* Old value */
	movq	%r8, %rax

	RET
	FRAME_END
SYM_FUNC_END(tdg_vm_wr)

SYM_FUNC_START(tdcs_ctls_set)
	FRAME_BEGIN

	movq	$TDCS_TD_CTLS, %rdx
	xorl	%ecx, %ecx
	movq	%rdi, %r8
	movq	%rdi, %r9

	tdcall $TDG_VM_WR

	testq	%rax, %rax
	setz	%al

	RET
	FRAME_END
SYM_FUNC_END(tdcs_ctls_set)

SYM_FUNC_START(tdg_sys_rd)
	FRAME_BEGIN

	xorl	%ecx, %ecx
	movq	%rdi, %rdx

	tdcall_or_panic $TDG_SYS_RD

	movq	%r8, %rax

	RET
	FRAME_END
SYM_FUNC_END(tdg_sys_rd)

SYM_FUNC_START(tdg_vp_veinfo_get)
	FRAME_BEGIN

	tdcall_or_panic $TDG_VP_VEINFO_GET

	save_output struct_reg=rdi regs=rcx,rdx,r8,r9,r10

	FRAME_END
	RET
SYM_FUNC_END(tdg_vp_veinfo_get)

SYM_FUNC_START(tdg_vp_info)
	FRAME_BEGIN

	tdcall_or_panic $TDG_VP_INFO

	save_output struct_reg=rdi regs=rcx,rdx,r8,r9,r10,r11

	FRAME_END
	RET
SYM_FUNC_END(tdg_vp_info)

SYM_FUNC_START(tdg_mem_page_accept)
	FRAME_BEGIN

	movq	%rdi, %rcx

	tdcall $TDG_MEM_PAGE_ACCEPT

	FRAME_END
	RET
SYM_FUNC_END(tdg_mem_page_accept)

SYM_FUNC_START(tdg_mr_report)
	FRAME_BEGIN

	movq	%rdx, %r8
	movq	%rdi, %rcx
	movq	%rsi, %rdx

	tdcall $TDG_MR_REPORT

	FRAME_END
	RET
SYM_FUNC_END(tdg_mr_report)

Lpanic:
	ud2
-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ