linux-kernel - [RFC PATCH 0/3] mshv: Add kexec safety for deposited pages

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]

Message-ID: 
 <176927917602.26405.4149319776242398706.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
Date: Sat, 24 Jan 2026 18:42:09 +0000
From: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
To: pasha.tatashin@...een.com, rppt@...nel.org, pratyush@...nel.org,
 kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
 decui@...rosoft.com, longli@...rosoft.com
Cc: linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/3] mshv: Add kexec safety for deposited pages

This is an RFC series. The goal is to discuss an approach; it is not
intended for merging as-is.

Microsoft Hypervisor is active, the kernel cannot access pages that have
been deposited to the hypervisor; doing so can trigger a GPF. The “pages
deposited” state is also lost across kexec, and the next kernel has no way
to know which pages are still owned/managed by the hypervisor.

Until a proper handoff of that state to the next kernel exists, kexec (and
liveupdate-based transitions) must be refused whenever there is shared
state that cannot safely survive the transition (in particular, deposited
pages; also running VMs).

What MSHV needs (until proper state preservation is ready) is simply a callback into the driver at the “freeze” stage
so it can:
 - refuse the transition while VMs are running
 - attempt to withdraw deposited pages (L1VH host case)
 - fail the transition if any pages remain deposited

Current liveupdate/LUO interfaces are primarily userspace-facing and are
structured around file/FD preservation. In order to reuse the existing
freeze sequencing with minimal churn, this RFC adapts a small part of the
LUO/file plumbing to allow a kernel user (mshv driver) to register into
that flow. This results in creating a session file solely as a vehicle to
get the freeze callback invoked, which is acknowledged to be awkward.

The intent of posting this is to get feedback on:
  - whether reusing the existing file-based liveupdate hooks for a pure
    in-kernel “freeze veto” is acceptable, or
  - whether we should instead introduce a dedicated kernel-side
    registration API (e.g. a notifier-style “freeze blockers” interface)
    that does not involve files at all.

---

Stanislav Kinsburskii (3):
      luo: Extract file object logic
      mshv: Account pages deposited to hypervisor
      mshv: Block kexec when hypervisor has pages deposited

 MAINTAINERS                      |    1 
 drivers/hv/Kconfig               |    1 
 drivers/hv/Makefile              |    1 
 drivers/hv/hv_proc.c             |    4 +
 drivers/hv/mshv_luo.c            |  113 ++++++++++++++++++++++++++++++++++++++
 drivers/hv/mshv_root.h           |   14 +++++
 drivers/hv/mshv_root_hv_call.c   |    2 +
 drivers/hv/mshv_root_main.c      |    7 ++
 include/linux/kho/abi/mshv.h     |   14 +++++
 include/linux/liveupdate.h       |    3 +
 kernel/liveupdate/luo_file.c     |   55 +++++++++++++++---
 kernel/liveupdate/luo_internal.h |    2 -
 kernel/liveupdate/luo_session.c  |    2 -
 13 files changed, 208 insertions(+), 11 deletions(-)
 create mode 100644 drivers/hv/mshv_luo.c
 create mode 100644 include/linux/kho/abi/mshv.h