linux-kernel - Re: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87frd1figp.fsf@redhat.com>
Date: Fri, 05 Sep 2025 10:48:22 +0300
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Wei Liu <wei.liu@...nel.org>
Cc: linux-hyperv@...r.kernel.org, Michael Kelley <mhklinux@...look.com>, "K.
 Y. Srinivasan" <kys@...rosoft.com>, Haiyang Zhang
 <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
 <decui@...rosoft.com>, x86@...nel.org, linux-kernel@...r.kernel.org, Nuno
 Das Neves <nunodasneves@...ux.microsoft.com>, Tianyu Lan
 <tiala@...rosoft.com>, Li Tian <litian@...hat.com>, Philipp Rudo
 <prudo@...hat.com>
Subject: Re: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs

Wei Liu <wei.liu@...nel.org> writes:

> On Thu, Aug 28, 2025 at 12:16:18PM +0300, Vitaly Kuznetsov wrote:
>> Azure CVM instance types featuring a paravisor hang upon kdump. The
>> investigation shows that makedumpfile causes a hang when it steps on a page
>> which was previously share with the host
>> (HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
>> knowledge of these 'special' regions (which are Vmbus connection pages,
>> GPADL buffers, ...). There are several ways to approach the issue:
>> - Convey the knowledge about these regions to the new kernel somehow.
>> - Unshare these regions before accessing in the new kernel (it is unclear
>> if there's a way to query the status for a given GPA range).
>> - Unshare these regions before jumping to the new kernel (which this patch
>> implements).
>> 
>> To make the procedure as robust as possible, store PFN ranges of shared
>> regions in a linked list instead of storing GVAs and re-using
>> hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
>> on the kdump/kexec path.
>> 
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
>
> No fixes tag for this one?
>

Personally, I don't see this as a 'bug', it's rather a missing
feature. In theory, we can add something like

Fixes: 810a52126502 ("x86/hyperv: Add new hvcall guest address host visibility support")

but I'm on the fence whether this is accurate or not.

> Should it be marked as a stable backport?

I think it may make sense even without an explicit 'Fixes:': kdump is the
user's last resort when it comes to kernel crashes and doubly so on
CVMs. Pure kexec may also come handy.

-- 
Vitaly