Re: [GIT PULL] Crypto Fixes for 6.16

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jun 25, 2025 at 11:14:23AM +0800, Herbert Xu wrote:
> On Tue, Jun 24, 2025 at 08:04:04PM -0700, Eric Biggers wrote:
> >
> > Wouldn't it make more sense to revert the "Crypto API partial block handling"
> > stuff?  It's been causing a huge number of problems, and it's been getting
> > superseded by the librarification changes anyway.
> 
> The partial block handling simplifies the implementation of both
> software and hardware hash algorithms.  Just look at the diffstat.

Not software, since the library functions have to handle partial blocks anyway.
There will be a negative diffstat for algorithms that haven't been converted to
have a library API yet, but it will go away once they are.

> > Indeed, I just found that a lot of drivers in drivers/crypto/ haven't been
> > updated to be aware of the extra byte that comes back from
> > crypto_shash_export().  So there are a bunch of buffer overflows there too.
> > (Not like drivers/crypto/ actually matters, but apparently your changes are for
> > its benefit?  So it's interesting that it was actually broken by them.)
> 
> If anything this proves that enforcing a consistent hash format
> is the right thing to do.  All those buggy code paths were assuming
> that the export format is fixed which was not the case prior to the
> partial blocks work.
> 
> But thanks for pointing me to these buggy drivers and I will send
> out fixes for them.

Well, they (reasonably enough) assume the format that all the CPU-based code
previously used.  So they weren't really broken until your changes.

Of course, the lack of type safety here is an artificial problem created by the
generic crypto API which uses a 'void *' state.  The library functions simply
use the C type system, so they just work and do not have this sort of silly
issue where different places disagree about what struct a 'void *' points to...

These legacy drivers should just use the library functions.

- Eric