From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA14C345731 for ; Thu, 11 Jun 2026 09:18:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781169512; cv=none; b=DB4hiyRonJUvFA1GVaT2za9IsFK5b75kATyWGINrDoWzNccmHgrN0p2hJMPEQnCrXBF1l4x3nO+in9M6NCMGW4kzroEdjOLjfPssCaPELhyfYKSYP8Mgplk1r8yCJkCWHGyeAKDo57RrAWNMBNFR63aDxwTmSJVAOC1vV1posGs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781169512; c=relaxed/simple; bh=EwTfVPjTiDUDQ0d4umOokZR+N9xUJJDD4t5etdVWbcg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=VMIDP5t3fwFvz3JD1V3FzucNE282yi/RqFAMW8sdbRa+6njgtOUGmrBl2zYuh+RP5sa6gsN6eVpttitsa0M4ubdui+HhPgWPZ4bevzds6ldSIzzkYjRZDVU/d5Blo6A0Nq0oqsqiFA7qKRbopXV3iuh+KE4c2ErMhs43dF98LhI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lU5HDb6K; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lU5HDb6K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCCF21F00893; Thu, 11 Jun 2026 09:18:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781169511; bh=bWzKKA513sGWS7gystdQPOj/dPx2tvXmn4sVux70dh4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=lU5HDb6KEPuf+i5iweN+1uq4PzaRUar82asCxKXNZoZVLuD2maPIYQxVhbxLTYYs8 TfLn48EvXODOG+vZdJc1UAJISJo9ScuculIfqLv0Y6PrDKIndAGPztAdMiQg5NUt+w EaYzx2iODXJ3g034ttKNtUeSK6GMXCG8yKMc8TRvGI7EOlJpkJv/1UZMsQ7vep4uI7 QRxvwrKlZDh2TJ84kJg1bcU1V1bvKYSx8qRebPQXgwBny9KmtQSWc7NmssGQ4Bv5yd nkyRHgHQYq303ENlT3ZfbeKSt55TD2R1IfkiRgcqrMX0jRYHz04rS6sSiF3XXn82Gh bF403Ri4fxFRA== From: Pratyush Yadav To: Kees Cook Cc: Michal Clapinski , Tony Luck , "Guilherme G. Piccoli" , Pasha Tatashin , Mike Rapoport , Pratyush Yadav , Alexander Graf , linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: Re: [PATCH v2] pstore: add a KHO backend In-Reply-To: <202606101331.BDB11F097@keescook> (Kees Cook's message of "Wed, 10 Jun 2026 13:34:10 -0700") References: <20260605121040.1177072-1-mclapinski@google.com> <202606101331.BDB11F097@keescook> Date: Thu, 11 Jun 2026 11:18:28 +0200 Message-ID: <2vxzzf11qvtn.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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 > > 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