linux-kernel - Re: [PATCH 1/2] liveupdate: kho: warn and fail on metadata or preserved memory in scratch area

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: <mafs0qzv4jomq.fsf@kernel.org>
Date: Wed, 15 Oct 2025 15:11:41 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  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,
  rdunlap@...radead.org,  rppt@...nel.org,  tj@...nel.org,
  jasonmiu@...gle.com,  dmatlack@...gle.com,  skhawaja@...gle.com
Subject: Re: [PATCH 1/2] liveupdate: kho: warn and fail on metadata or
 preserved memory in scratch area

On Wed, Oct 15 2025, Pasha Tatashin wrote:

> On Wed, Oct 15, 2025 at 8:10 AM Pratyush Yadav <pratyush@...nel.org> wrote:
>>
>> On Wed, Oct 15 2025, Pasha Tatashin wrote:
>>
>> > It is invalid for KHO metadata or preserved memory regions to be located
>> > within the KHO scratch area, as this area is overwritten when the next
>> > kernel is loaded, and used early in boot by the next kernel. This can
>> > lead to memory corruption.
>> >
>> > Adds checks to kho_preserve_* and KHO's internal metadata allocators
>> > (xa_load_or_alloc, new_chunk) to verify that the physical address of the
>> > memory does not overlap with any defined scratch region. If an overlap
>> > is detected, the operation will fail and a WARN_ON is triggered. To
>> > avoid performance overhead in production kernels, these checks are
>> > enabled only when CONFIG_KEXEC_HANDOVER_DEBUG is selected.
>> >
>> > Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
>> > ---
>> >  kernel/liveupdate/Kconfig                   | 15 ++++++++++
>> >  kernel/liveupdate/kexec_handover.c          | 32 ++++++++++++++++++---
>> >  kernel/liveupdate/kexec_handover_debug.c    | 18 ++++++++++++
>> >  kernel/liveupdate/kexec_handover_internal.h |  9 ++++++
>> >  4 files changed, 70 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/kernel/liveupdate/Kconfig b/kernel/liveupdate/Kconfig
>> > index 522b9f74d605..d119f4f3f4b1 100644
>> > --- a/kernel/liveupdate/Kconfig
>> > +++ b/kernel/liveupdate/Kconfig
>> > @@ -27,4 +27,19 @@ config KEXEC_HANDOVER_DEBUGFS
>> >         Also, enables inspecting the KHO fdt trees with the debugfs binary
>> >         blobs.
>> >
>> > +config KEXEC_HANDOVER_DEBUG
>> > +     bool "Enable Kexec Handover debug checks"
>> > +     depends on KEXEC_HANDOVER_DEBUGFS
>>
>> Why the dependency on debugfs? Why can't the debug checks be enabled
>> independently?
>
> Because there is one kexec_handover_debug.c file, that I thought would
> make sense to use for both, but now thinking about this, perhaps we
> should split the code: KEXEC_HANDOVER_DEBUGFS and
> KEXEC_HANDOVER_DEBUG, and add two files:
> kexec_handover_debugfs.c and kexec_handover_debug.c, this would avoid
> ifdefs in .c.

Sounds good.

>
>>
>> > +     help
>> > +       This option enables extra sanity checks for the Kexec Handover
>> > +       subsystem.
>> > +
>> > +       These checks verify that neither preserved memory regions nor KHO's
>> > +       internal metadata are allocated from within a KHO scratch area.
>> > +       An overlap can lead to memory corruption during a subsequent kexec
>> > +       operation.
>>
>> I don't think the checks that are done should be listed here since as
>> soon as another check is added this list will become out of date.
>
> I thought it could be expanded when new features are added, but I can
> remove this description.

Yes, but it is easy to forget to do so.

>
>>
>> > +
>> > +       If an overlap is detected, the kernel will print a warning and the
>> > +       offending operation will fail. This should only be enabled for
>>
>> This also describes the behaviour of the checks, which might change
>> later. Maybe for some checks the operation won't fail? I suppose just
>> leave it at "the kernel will print a warning"?
>
> If it changes, and Kconfig should be updated as well.
>
>>
>> > +       debugging purposes due to runtime overhead.
>> >  endmenu
[...]

-- 
Regards,
Pratyush Yadav