linux-kernel - Re: [PATCH] mshv: Make MSHV mutually exclusive with KEXEC

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: <aXo2X4mRioTa3sBl@anirudh-surface.localdomain>
Date: Wed, 28 Jan 2026 16:16:31 +0000
From: Anirudh Rayabharam <anirudh@...rudhrb.com>
To: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
Cc: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
	decui@...rosoft.com, longli@...rosoft.com,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mshv: Make MSHV mutually exclusive with KEXEC

On Mon, Jan 26, 2026 at 12:46:44PM -0800, Stanislav Kinsburskii wrote:
> On Tue, Jan 27, 2026 at 12:19:24AM +0530, Anirudh Rayabharam wrote:
> > On Fri, Jan 23, 2026 at 10:20:53PM +0000, Stanislav Kinsburskii wrote:
> > > The MSHV driver deposits kernel-allocated pages to the hypervisor during
> > > runtime and never withdraws them. This creates a fundamental incompatibility
> > > with KEXEC, as these deposited pages remain unavailable to the new kernel
> > > loaded via KEXEC, leading to potential system crashes upon kernel accessing
> > > hypervisor deposited pages.
> > > 
> > > Make MSHV mutually exclusive with KEXEC until proper page lifecycle
> > > management is implemented.
> > 
> > Someone might want to stop all guest VMs and do a kexec. Which is valid
> > and would work without any issue for L1VH.
> > 
> 
> No, it won't work and hypervsisor depostied pages won't be withdrawn.

All pages that were deposited in the context of a guest partition (i.e.
with the guest partition ID), would be withdrawn when you kill the VMs,
right? What other deposited pages would be left?

Thanks,
Anirudh.

> Also, kernel consisntency must no depend on use space behavior. 
> 
> > Also, I don't think it is reasonable at all that someone needs to
> > disable basic kernel functionality such as kexec in order to use our
> > driver.
> > 
> 
> It's a temporary measure until proper page lifecycle management is
> supported in the driver.
> Mutual exclusion of the driver and kexec is given and thus should be
> expclitily stated in the Kconfig.
> 
> Thanks,
> Stanislav
> 
> > Thanks,
> > Anirudh.
> > 
> > > 
> > > Signed-off-by: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
> > > ---
> > >  drivers/hv/Kconfig |    1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> > > index 7937ac0cbd0f..cfd4501db0fa 100644
> > > --- a/drivers/hv/Kconfig
> > > +++ b/drivers/hv/Kconfig
> > > @@ -74,6 +74,7 @@ config MSHV_ROOT
> > >  	# e.g. When withdrawing memory, the hypervisor gives back 4k pages in
> > >  	# no particular order, making it impossible to reassemble larger pages
> > >  	depends on PAGE_SIZE_4KB
> > > +	depends on !KEXEC
> > >  	select EVENTFD
> > >  	select VIRT_XFER_TO_GUEST_WORK
> > >  	select HMM_MIRROR
> > > 
> > >