Re: git: cfb7b942bed7 - main - cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers.
Date: Tue, 18 Jan 2022 08:11:31 UTC
On 18/01/22 01:06, Mark Johnston wrote: > On Mon, Jan 17, 2022 at 10:30:05PM +0100, Guido Falsi wrote: >> 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 <jhb@FreeBSD.org> >>>>> AuthorDate: 2022-01-11 22:18:57 +0000 >>>>> Commit: John Baldwin <jhb@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! > > I committed it just now, after some private discussion with John. > Thanks for the report and for testing. > Thanks a lot to both of you! -- Guido Falsi <madpilot@FreeBSD.org>