linux-kernel - Re: [PATCH v5 3/5] hyperv: Enable the hypercall output page for the VTL mode

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: <20250107191848.GA24369@skinsburskii.>
Date: Tue, 7 Jan 2025 11:18:48 -0800
From: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
To: Roman Kisel <romank@...ux.microsoft.com>
Cc: hpa@...or.com, kys@...rosoft.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, decui@...rosoft.com,
	eahariha@...ux.microsoft.com, haiyangz@...rosoft.com,
	mingo@...hat.com, mhklinux@...look.com,
	nunodasneves@...ux.microsoft.com, tglx@...utronix.de,
	tiala@...rosoft.com, wei.liu@...nel.org,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, apais@...rosoft.com, benhill@...rosoft.com,
	ssengar@...rosoft.com, sunilmut@...rosoft.com, vdso@...bites.dev
Subject: Re: [PATCH v5 3/5] hyperv: Enable the hypercall output page for the
 VTL mode

On Mon, Jan 06, 2025 at 01:07:25PM -0800, Roman Kisel wrote:
> 
> 
> On 1/6/2025 11:32 AM, Stanislav Kinsburskii wrote:
> > On Mon, Jan 06, 2025 at 10:11:16AM -0800, Roman Kisel wrote:
> [...]s
> 
> > From my POV a decision between a unified approach and interim solutions
> > in upstream should usually be resolved in favor of the former.
> > Given there are different stake holders in VTL code integration, I'd
> > suggest we step back a bit and think about how to proceed with the
> > overall design.
> I don't see any compelling reason for stalling this fix and think for
> no one knows how long. What is going to be fixed is clear, and it has
> not been demonstrated what is going to be broken when this change is
> merged.
> 
> > 
> > In my opinion, although I undestand why Underhill project decided to
> > come up with the original VTL kernels separation during build time, it's
> > time to reconsider this approach and to come up with a more generic
> > design, supporting booting the same kernel in different VTLs.
> "The same kernel" means supporting ACPI/UEFI for VTL0, VTL1, VTL2 as
> otherwise VTL0 won't boot. But why would VTL>0 even consider relying on
> ACPI or compiling it in? I would fix your broad assertion with adding
> one constraint: share as much Hyper-V code as possible, booting is not
> expected, rather refuse building.
> 
> > 
> > The major reason for this is that LVBS project relies on binary
> > compatibility of the kernels running in different VTLs.
> > The simplest way to provide such a guarantee in both development and
> > deployment is to run the same kernel in both VTLs.
> 
> OpenHCL aka Underhill is the only shipping product relying on
> the code in question (others might be dom0 and LVBS). What the LVBS
> project relies on might change any number of times any day before it
> ships. OpenHCL works for customers and slicing and dicing it ought to
> be well thought through.
> 
> > Not having this ability will require carefull crafting of both the
> > kernels upon build, making kexec servicing of such kernels in production
> > complicated and error prone.
> 
> Too vague, imho. I'd respond that "careful crafting" shouldn't lead to
> being complicated and error prone as long as it's automatic and, well,
> careful.
> 
> It is harder and harder to me to see how enabling the hypercall output
> page is related to where the discussion has drifted. My claims are:
> 
> * enabling the hypercall output page poses no harm (doesn't break hyper-
> next),
> * allows to bring the code to the clear and concise form of getting a VP
> register.
> 
> Can you refute any of that?
> 

My point is that the proposed fix looks more like an Underhill-tailored
bandage and doesn't take the needs of other stake holders into
consideration.

What is the urgency in merging of this particular change?

Thanks,
Stas