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--cVCsfWxk427qE@infradead.org>
Date: Fri, 4 Apr 2025 01:46:12 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
	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>,
	David Howells <dhowells@...hat.com>
Subject: Re: Chaining is dead

On Mon, Mar 31, 2025 at 04:56:30PM +0000, Eric Biggers wrote:
> > My strategy is to allocate the whole thing if we can (2KB or 4KB
> > depending on your digest size), and if that fails, fall back to
> > a stack buffer of 512 bytes (or whatever number that keeps the
> > compiler quiet regarding stack usage).  Even if we're on the stack,
> > it should still give more than enough to data to satiate your
> > multibuffer hash code.
> 
> Extending the generic crypto infrastructure to support bios and folios is an
> interesting idea.

The right way to do that is to make it work on an iov_iter.  David
Howells talked about that at LSF/MM and might even have done that work
at least at a POC level.  That way you can trivially pass in a bio
because it's just an ITER_BVEC iter, and for a folio you'd build a
single entry bvec.

The primary intent here is to avoid building the scatterlist for crypto
work in network file systems, but just about any other caller would
benefit as well, but that scatterlist isn't a good fit for any of the
callers I've looked at, it a really bad fit for software crypto and at
least once we get the new two step DMA API also a bad fit for hardware
offload.