linux-kernel - Re: [PATCH v10 1/8] x86/vmware: Introduce VMware hypercall API

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: <20240603175844.GKZl4EVGUxp2aQZnYJ@fat_crate.local>
Date: Mon, 3 Jun 2024 19:58:44 +0200
From: Borislav Petkov <bp@...en8.de>
To: Alexey Makhalov <alexey.makhalov@...adcom.com>
Cc: linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
	hpa@...or.com, dave.hansen@...ux.intel.com, mingo@...hat.com,
	tglx@...utronix.de, x86@...nel.org, netdev@...r.kernel.org,
	richardcochran@...il.com, linux-input@...r.kernel.org,
	dmitry.torokhov@...il.com, zackr@...are.com,
	linux-graphics-maintainer@...are.com, pv-drivers@...are.com,
	timothym@...are.com, akaher@...are.com,
	dri-devel@...ts.freedesktop.org, daniel@...ll.ch, airlied@...il.com,
	tzimmermann@...e.de, mripard@...nel.org,
	maarten.lankhorst@...ux.intel.com, horms@...nel.org,
	kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v10 1/8] x86/vmware: Introduce VMware hypercall API

On Wed, May 29, 2024 at 05:44:32PM -0700, Alexey Makhalov wrote:
> While most of the vmware_hypercall callers are executed after alternative
> patching applied, there are small amount of hypercalls running before that.
> Only for them we have the logic of analyzing vmware_hypercall_mode as a
> default alternative code. And there are 2 constraints:
> 1. vmcall/vmmcall are not supported by old ESXi/Workstation/Fusion. We have
> to use in/out instructions. After the end of support of old hypervisors the
> alternative can be simplified as follow:
> ALTERNATIVE("vmcall", "vmmcall", X86_FEATURE_VMW_VMMCALL);
> 2. SEV-ES enabled VMs should use _only_ vmcall/vmmcall as in/out
> instructions cause faults.
> 
> Another approach that we discussed internally was to use
> ALTERNATIVE_2("movw %[port], %%dx; "inl (%%dx), %%eax", "vmcall",
> X86_FEATURE_VMW_VMCALL, "vmmcall", X86_FEATURE_VMW_VMMCALL) for
> vmware_hypercallX family of functions, _and_ to have a separate API
> vmware_sev_hypercallX, with the silly dance without an alternative inside,
> to be used only by early boot code, before alternative application. But,
> it's error prone when things come to boot time related code movements or
> rearrangements as it puts additional requirement for SEV-ES
> understanding/testing for VMware guests.

Right, so since we're exporting that alternatives_patched thing already,
you might also try to do:

	if (unlikely(!alternatives_patched))
		return slow_hypercall_X_in_c();

	asm_inline volatile(VMWARE_HYPERCALL...

where that slow_hypercall_X_in_c()* set of APIs does the checks in C.

And the VMWARE_HYPERCALL thing is a lot simpler then.

All in all, you'll have a lot less unreadable asm to pay attention to
and those APIs should be all easy and readable.

But in the end of the day, your call.

Thanks for explaining the situation.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette