linux-kernel - [PATCH RFC] Drivers: hv: balloon: Temporary disable the driver on ARM64 when PAGE

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-next>] [day] [month] [year] [list]

Date:   Wed,  5 Jan 2022 17:50:28 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     linux-hyperv@...r.kernel.org
Cc:     "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
        Michael Kelley <mikelley@...rosoft.com>,
        Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org
Subject: [PATCH RFC] Drivers: hv: balloon: Temporary disable the driver on ARM64 when PAGE_SIZE != 4k

Hyper-V ballooning and memory hotplug protocol always seems to assume
4k page size so all PFNs in the structures used for communication are
4k PFNs. In case a different page size is in use on the guest (e.g.
64k), things go terribly wrong all over:
- When reporting statistics, post_status() reports them in guest pages
and hypervisor sees very low memory usage.
- When ballooning, guest reports back PFNs of the allocated pages but
the hypervisor treats them as 4k PFNs.
- When unballooning or memory hotplugging, PFNs coming from the host
are 4k PFNs and they may not even be 64k aligned making it difficult
to handle.

While statistics and ballooning requests would be relatively easy to
handle by converting between guest and hypervisor page sizes in the
communication structures, handling unballooning and memory hotplug
requests seem to be harder. In particular, when ballooning up
alloc_balloon_pages() shatters huge pages so unballooning request can
be handled for any part of it. It is not possible to shatter a 64k
page into 4k pages so it's unclear how to handle unballooning for a
sub-range if such request ever comes so we can't just report a 64k
page as 16 separate 4k pages.

Ideally, the protocol between the guest and the host should be changed
to allow for different guest page sizes.

While there's no solution for the above mentioned problems, it seems
we're better off without the driver in problematic cases.

Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
---
 drivers/hv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 0747a8f1fcee..fb353a13e5c4 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -25,7 +25,7 @@ config HYPERV_UTILS

 config HYPERV_BALLOON
 	tristate "Microsoft Hyper-V Balloon driver"
-	depends on HYPERV
+	depends on HYPERV && (X86 || (ARM64 && ARM64_4K_PAGES))
 	select PAGE_REPORTING
 	help
 	  Select this option to enable Hyper-V Balloon driver.
-- 
2.33.1