On 15/01/22 01:26, Mark Johnston wrote:
On Fri, Jan 14, 2022 at 10:27:12PM +0100, Guido Falsi wrote:
On 11/01/22 23:38, John Baldwin wrote:
The branch main has been updated by jhb:
URL:
https://cgit.FreeBSD.org/src/commit/?id=cfb7b942bed72cb798b869d2e36e0097dbd243b2
commit cfb7b942bed72cb798b869d2e36e0097dbd243b2
Author: John Baldwin <j...@freebsd.org>
AuthorDate: 2022-01-11 22:18:57 +0000
Commit: John Baldwin <j...@freebsd.org>
CommitDate: 2022-01-11 22:18:57 +0000
cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33531
Hi,
I've just updated to recent head. I have a laptop using ZFS on geli
setup and now it's unable to boot.
I've seen the failure starting with git revision
3284f4925f697ad7cc2aa4761ff5cf6ce98fd623 (LRO: Don't merge ACK and
non-ACK packets together - 01/13/22, 17:18)
it's still there with revision fe453891d7ccc8e173d9293b67f5b4608c5378dd
(01/14/22 11:00:08)
While a kernel from the binary snapshot downloaded from mirrors compiled
from revision ac413189f53524e489c900b3cfaa80a1552875ca (vfslist.c:
initialize skipvfs variable 01/05/2022) is able to boot correctly.
The machine panics as soon as it tries to work with geli, this is why I
am replying to this commit message. I'm not completely sure this is the
commit to blame, but it sure is related.
I have not been able to save the backtrace to file, but the last two
calls are to:
crypto_cursor_segment()
swcr_encdec()
so it points to the last part of this patch.
I think the problem is that crypto_cursor_segment() doesn't expect to be
called once the cursor is at the end of a buffer. It may or may not
perform an invalid memory access in that case, depending on the
underlying buffer type.
Fixing it would complicate the cursor code, maybe it's better to just
change cryptosoft to avoid this scenario:
Is this being followed up? Ads I said this patch works for me and I'm
using it locally. While I'm unable to review it, as a user and
contributor I'm interested in the issue being fixed for good in the
official tree.
If discussion is already ongoing in a publicly accessible can you point
me to it? Thanks!
--
Guido Falsi <madpi...@freebsd.org>
