linux-kernel - Re: [PATCH 2/2] hyperv: Do not overlap the input and output hypercall areas in get

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: <9c138f4e-9258-4457-b85b-69ae111894fb@linux.microsoft.com>
Date: Thu, 26 Dec 2024 08:45:34 -0800
From: Roman Kisel <romank@...ux.microsoft.com>
To: Michael Kelley <mhklinux@...look.com>, Wei Liu <wei.liu@...nel.org>
Cc: "hpa@...or.com" <hpa@...or.com>, "kys@...rosoft.com" <kys@...rosoft.com>,
 "bp@...en8.de" <bp@...en8.de>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "decui@...rosoft.com" <decui@...rosoft.com>,
 "eahariha@...ux.microsoft.com" <eahariha@...ux.microsoft.com>,
 "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
 "mingo@...hat.com" <mingo@...hat.com>,
 "nunodasneves@...ux.microsoft.com" <nunodasneves@...ux.microsoft.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "tiala@...rosoft.com" <tiala@...rosoft.com>,
 "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "x86@...nel.org" <x86@...nel.org>, "apais@...rosoft.com"
 <apais@...rosoft.com>, "benhill@...rosoft.com" <benhill@...rosoft.com>,
 "ssengar@...rosoft.com" <ssengar@...rosoft.com>,
 "sunilmut@...rosoft.com" <sunilmut@...rosoft.com>,
 "vdso@...bites.dev" <vdso@...bites.dev>
Subject: Re: [PATCH 2/2] hyperv: Do not overlap the input and output hypercall
 areas in get_vtl(void)



On 12/24/2024 8:45 AM, Michael Kelley wrote:

[...]

> 
> OK, my understanding is that your concern about spec conformance is
> just that Linux should be able to allocate enough input and output space
> for the maximum case, which is 4KiB of input *plus* 4KiB of output. If
> the total amount of input plus output for a particular hypercall is less
> than 4KiB, then there's no conformance problem with having the input
> and output share a page, as long as the "no overlap" rule is observed.
>
Appreciate bearing with me and guiding me towards expressing the intent
clearer :) Yes, the logic chain has been:

* can't overlap input and output due to TLFS req's =>
* need to fix get_vtl() *&&* dom0 uses the output page *&&* VTLs use
   the output page =>
* let us fix the overlap *&&* make get_vtl() look as get_vp_register()
   as this is what it actually is so soon we should be able to have less
   code.

Getting rid of the hypercall output page feels like too much as if the
code base is dovetailed to that and the hypervisor gets a hypercall
whose output is as large as a page (however unlikely that sounds, but
first there was an opinion that 640KiB is plenty, then 32 address lines,
then 48 bits in the PA and 4 level pages, then 57 bits and 5 levels,
...), we'd need to fix the code or allocate and deallocate on demand.
That tradeoff b/w saving a page and adding special cases makes me lean
to just allocate the page as it is allocated anyway.

> There's an idea kicking around in my head about a different way to
> handle all this that might be cleaner and less code all-around. If I
> get motivated, I may code it up and see if it really works. If so,
> I'll run it by you to see what you think.
MUCH appreciated!! The complexity appears to be increasing over time,
and it would be incredible to pack all we got into less code without
constraining ourselves too much :)

> 
> Michael

-- 
Thank you,
Roman