[PATCH v2] pstore: add a KHO backend

[Pratyush Yadav]

On Wed, Jun 10 2026, Kees Cook wrote:

> 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 at 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.

I'll do my usual piece about trust when using KHO. You _have_ to trust
the previous kernel. KHO has no way of validating the information from
the previous kernel. It has to trust what it says. Because of this, the
previous kernel has a lot of influence on the state of the current
kernel. I don't think we can draw any sane security boundary here.

So I think if you are using KHO, you should rely on chain of trust or
other similar mechanisms to make sure you trust the previous kernel. KHO
itself can't provide much of a security model.

All that said, I think it makes perfect sense to do bounds checking. You
should still protect yourself from a _buggy_ kernel.

But be careful. Currently RECORD_MAX_SIZE depends on
CONFIG_LOG_BUF_SHIFT. This can change between kernel versions and
shouldn't be used to enforce correctness. Because otherwise, if the new
kernel sets a smaller CONFIG_LOG_BUF_SHIFT, it will reject perfectly
valid data. Come up with a reasonable value and use it as ABI. If you
ever need to change it, you can do so with an ABI version bump.

-- 
Regards,
Pratyush Yadav