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: <aPXz-IPDRniMHN0u@kernel.org>
Date: Mon, 20 Oct 2025 11:34:00 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: akpm@...ux-foundation.org, brauner@...nel.org, corbet@....net,
	graf@...zon.com, jgg@...pe.ca, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
	masahiroy@...nel.org, ojeda@...nel.org, pratyush@...nel.org,
	rdunlap@...radead.org, tj@...nel.org, jasonmiu@...gle.com,
	dmatlack@...gle.com, skhawaja@...gle.com
Subject: Re: [PATCH v6 00/10] liveupdate: Rework KHO for in-kernel users &
 Fix memory corruption

On Sat, Oct 18, 2025 at 01:17:46PM -0400, Pasha Tatashin wrote:
> This series addresses comments and combines into one the two
> series [1] and [2], and adds review-bys.
> 
> This series refactors the KHO framework to better support in-kernel
> users like the upcoming LUO. The current design, which relies on a
> notifier chain and debugfs for control, is too restrictive for direct
> programmatic use.
> 
> The core of this rework is the removal of the notifier chain in favor of
> a direct registration API. This decouples clients from the shutdown-time
> finalization sequence, allowing them to manage their preserved state
> more flexibly and at any time.
> 
> Also, this series fixes a memory corruption bug in KHO that occurs when
> KFENCE is enabled.
> 
> The root cause is that KHO metadata, allocated via kzalloc(), can be
> randomly serviced by kfence_alloc(). When a kernel boots via KHO, the
> early memblock allocator is restricted to a "scratch area". This forces
> the KFENCE pool to be allocated within this scratch area, creating a
> conflict. If KHO metadata is subsequently placed in this pool, it gets
> corrupted during the next kexec operation.
> 
> [1] https://lore.kernel.org/all/20251007033100.836886-1-pasha.tatashin@soleen.com
> [2] https://lore.kernel.org/all/20251015053121.3978358-1-pasha.tatashin@soleen.com
> 
> Mike Rapoport (Microsoft) (1):
>   kho: drop notifiers
> 
> Pasha Tatashin (9):
>   kho: allow to drive kho from within kernel
>   kho: make debugfs interface optional
>   kho: add interfaces to unpreserve folios and page ranes
>   kho: don't unpreserve memory during abort
>   liveupdate: kho: move to kernel/liveupdate
>   kho: move kho debugfs directory to liveupdate
>   liveupdate: kho: warn and fail on metadata or preserved memory in scratch area
>   liveupdate: kho: Increase metadata bitmap size to PAGE_SIZE
>   liveupdate: kho: allocate metadata directly from the buddy allocator

The fixes should go before the preparation for LUO or even better as a
separate series.

I've reread the LUO preparation patches and I don't think they are useful
on their own. They introduce a couple of unused interfaces and I think it's
better to have them along with the rest of LUO patches.

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ