linux-kernel - Re: Chaining is dead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z-td2eIxPp-gRq7n@gondor.apana.org.au>
Date: Tue, 1 Apr 2025 11:30:33 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Chaining is dead

On Mon, Mar 31, 2025 at 04:56:30PM +0000, Eric Biggers wrote:
>
> For hashing, users would need to allocate an array to hold the digest for every
> block in the bio or folio.  That would add an additional memory allocation to
> every I/O.  You said you'd like to fall back to a smaller buffer if the memory
> allocation fails.  But that's silly; if we have to support that anyway, we might
> as well do it that way only.  In which case the bio interface is pointless.

BTW, the existing verity code is hilarious.  In my test, for each
256KB bio, it was dividing them up into 4KB pages, and then for each
one of them, it's looking up the correct hash in the Merkle tree.

Surely there is some locality here so if you zoom out from 4KB (or
even 8KB with your multibuffer patch-set) to 256KB you could get all
the correct hashes in one go, rather than 64 times.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt