linux-kernel - RE: [PATCH v4 0/7] hyperv: Introduce new way to manage hypercall args

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:
 <SN6PR02MB4157A2A90910918AE9B6327BD45DA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Mon, 21 Jul 2025 02:19:55 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Roman Kisel <romank@...ux.microsoft.com>, Easwar Hariharan
	<eahariha@...ux.microsoft.com>, Nuno Das Neves
	<nunodasneves@...ux.microsoft.com>, Naman Jain <namjain@...ux.microsoft.com>
CC: "kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com"
	<haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
	"decui@...rosoft.com" <decui@...rosoft.com>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
	<bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"hpa@...or.com" <hpa@...or.com>, "lpieralisi@...nel.org"
	<lpieralisi@...nel.org>, "kw@...ux.com" <kw@...ux.com>, "mani@...nel.org"
	<mani@...nel.org>, "robh@...nel.org" <robh@...nel.org>, "bhelgaas@...gle.com"
	<bhelgaas@...gle.com>, "arnd@...db.de" <arnd@...db.de>, "x86@...nel.org"
	<x86@...nel.org>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "linux-arch@...r.kernel.org"
	<linux-arch@...r.kernel.org>
Subject: RE: [PATCH v4 0/7] hyperv: Introduce new way to manage hypercall args

From: Roman Kisel <romank@...ux.microsoft.com> Sent: Friday, July 18, 2025 6:16 PM
> 
> On 7/18/2025 1:25 PM, Easwar Hariharan wrote:
> > On 7/18/2025 10:13 AM, Michael Kelley wrote:
> >> From: Easwar Hariharan <eahariha@...ux.microsoft.com> Sent: Friday, July 18, 2025
> 9:33 AM
> >>>
> >>> On 7/17/2025 9:55 PM, mhkelley58@...il.com wrote:
> >>>> From: Michael Kelley <mhklinux@...look.com>
> >>>>
> >>
> >> [snip]
> >>
> >>>>
> >>>> The new code compiles and runs successfully on x86 and arm64. However,
> >>>> basic smoke tests cover only a limited number of hypercall call sites
> >>>> that have been modified. I don't have the hardware or Hyper-V
> >>>> configurations needed to test running in the Hyper-V root partition
> >>>> or running in a VTL other than VTL 0. The related hypercall call sites
> >>>> still need to be tested to make sure I didn't break anything. Hopefully
> >>>> someone with the necessary configurations and Hyper-V versions can
> >>>> help with that testing.
> >>
> >> Easwar --
> >>
> >> Thanks for reviewing.
> >>
> >> Any chance you (or someone else) could do a quick smoke test of this
> >> patch set when running in the Hyper-V root partition, and separately,
> >> when running in VTL2?  Some hypercall call sites are modified that
> >> don't get called in normal VTL0 execution. It just needs a quick
> >> verification that nothing is obviously broken for the root partition and
> >> VTL2 cases.
> >>
> >> Michael
> >>
> >
> > I'm working almost entirely in VTL0, so I'd call on Nuno, Naman, and Roman (cc'ed) to
> help.
> >
> 
> Michael,
> 
> I'll try to squeeze that in during the next week. Folks should feel free
> to beat me to that :) The caveat would be that there are scenarios that
> are beyond the capabilities of the hardware that I have readily
> available, and would need to run in test clusters in Azure, and these
> are pretty busy.

Thanks for any testing you can do on standalone test machines without
needing test clusters in Azure. It will be hard to get test coverage on
*every* hypercall call site that is modified by the patch set, but doing
basic smoke testing of running in the root partition and in VTL2 will
cover more than I can cover running in a VTL0 guest on my laptop or
in Azure. Fortunately, the changes overall in this patch set are pretty
straightforward, and my testing of VTL0 guests didn’t turn up any bugs.
I'm hoping that additional smoke testing is more about gaining
confidence than finding actual bugs.  (Famous last words ....)

> VTL2 currently uses a limited number hypercalls that are set as enabled
> in the OpenVMM code (`set_allowed_hypercalls`). You could take a look
> and conclude if these hypercalls require any adjustments in the patches.

My patch set already covers all the hypercall call sites that originate in
VTL2 code. Again, a basic smoke test should help gain confidence, or
show that any confidence is misplaced :-)

> My opinion has been to have two pages (input and output ones). As the
> new code introduces just one page I do feel a bit apprehensive, got no
> hard evidence that this is a bad approach though. If we tweak the code
> to have 2 pages, perhaps there would be no need to run a full-blown
> validation, and even smoke tests will suffice? 

My view is that the 1 page vs. 2 pages is much less of a risk than just
some coding error in introducing the new interfaces. The 1 page vs.
2 pages should only affect the batch size for rep hypercalls, and the
existing code already handles different batch sizes. So I'm not as
concerned about that risk. Wei Liu in the maintainer here, so I'll
certainly follow his judgment and guidance on what is needed to
be confident in this patch set.

Michael