From: Kees Cook <kees@kernel.org>
To: Michal Clapinski <mclapinski@google.com>
Cc: Tony Luck <tony.luck@intel.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Alexander Graf <graf@amazon.com>, Mike Rapoport <rppt@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH v2] pstore: add a KHO backend
Date: Wed, 10 Jun 2026 13:34:10 -0700 [thread overview]
Message-ID: <202606101331.BDB11F097@keescook> (raw)
In-Reply-To: <20260605121040.1177072-1-mclapinski@google.com>
On Fri, Jun 05, 2026 at 02:10:40PM +0200, Michal Clapinski wrote:
> Up to this point to preserve late shutdown logs in memory, users had to
> predefine a memory region using ramoops. This commit changes this by
> preserving a buffer using kexec-handover.
>
> pstore_kho supports preserving only 1 dmesg buffer.
> It gets replaced with the new buffer on every kexec, so the user has to
> copy the file out of pstore after every kexec.
> There is no erase() support.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
I'm a fan of the idea! I'd love to see a selftest added for this
backend, since it should be possible to do a direct tests for dmesg
preservation across a kexec in tools/testing/selftests/pstore/
There is still good feedback from sashiko, which caught everything I was going
to mention and then some:
https://sashiko.dev/#/patchset/20260605121040.1177072-1-mclapinski%40google.com
> ---
> v2:
> - Added a comment explaining the benefits of pstore_kho.
> - Created include/linux/kho/abi/pstore.h.
> - Got rid of the KHO subtree.
> - Made sure never to free incoming kho data.
> This way the module can be safely reloaded.
> - Sashiko complained that I trust the data coming from the old kernel.
> I ignored it. LMK if I shouldn't trust the old kernel.
We shouldn't trust the old kernel. :) Sashiko's suggestion here seems
reasonable which is to at least bounds-check the size against
RECORD_MAX_SIZE since that's the largest it should ever be.
-Kees
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <kees@kernel.org>
To: Michal Clapinski <mclapinski@google.com>
Cc: Tony Luck <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH v2] pstore: add a KHO backend
Date: Wed, 10 Jun 2026 13:34:10 -0700 [thread overview]
Message-ID: <202606101331.BDB11F097@keescook> (raw)
In-Reply-To: <20260605121040.1177072-1-mclapinski@google.com>
On Fri, Jun 05, 2026 at 02:10:40PM +0200, Michal Clapinski wrote:
> Up to this point to preserve late shutdown logs in memory, users had to
> predefine a memory region using ramoops. This commit changes this by
> preserving a buffer using kexec-handover.
>
> pstore_kho supports preserving only 1 dmesg buffer.
> It gets replaced with the new buffer on every kexec, so the user has to
> copy the file out of pstore after every kexec.
> There is no erase() support.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
I'm a fan of the idea! I'd love to see a selftest added for this
backend, since it should be possible to do a direct tests for dmesg
preservation across a kexec in tools/testing/selftests/pstore/
There is still good feedback from sashiko, which caught everything I was going
to mention and then some:
https://sashiko.dev/#/patchset/20260605121040.1177072-1-mclapinski%40google.com
> ---
> v2:
> - Added a comment explaining the benefits of pstore_kho.
> - Created include/linux/kho/abi/pstore.h.
> - Got rid of the KHO subtree.
> - Made sure never to free incoming kho data.
> This way the module can be safely reloaded.
> - Sashiko complained that I trust the data coming from the old kernel.
> I ignored it. LMK if I shouldn't trust the old kernel.
We shouldn't trust the old kernel. :) Sashiko's suggestion here seems
reasonable which is to at least bounds-check the size against
RECORD_MAX_SIZE since that's the largest it should ever be.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2026-06-10 20:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 12:10 [PATCH v2] pstore: add a KHO backend Michal Clapinski
2026-06-10 20:34 ` Kees Cook [this message]
2026-06-10 20:34 ` Kees Cook
2026-06-11 9:18 ` Pratyush Yadav
2026-06-11 9:18 ` Pratyush Yadav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202606101331.BDB11F097@keescook \
--to=kees@kernel.org \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mclapinski@google.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.