Re: git: cfb7b942bed7 - main - cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers.
- Reply: Guido Falsi : "Re: git: cfb7b942bed7 - main - cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers."
- In reply to: Guido Falsi : "Re: git: cfb7b942bed7 - main - cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 18 Jan 2022 00:06:48 UTC
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.