Re: git: cfb7b942bed7 - main - cryptosoft: Use multi-block encrypt/decrypt for non-AEAD ciphers.

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!

-- 
Guido Falsi <madpilot@FreeBSD.org>