Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [GIT PULL] Crypto Fixes for 6.16
Date: Wed, 25 Jun 2025 11:14:23 +0800	[thread overview]
Message-ID: <aFtpj5y4HtzVDChg@gondor.apana.org.au> (raw)
In-Reply-To: <20250625030404.GA8962@sol>

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.

In this particular instance, I thought nobody used hmac on wp512
which is why I didn't do the conversion for it initially.  But
apparently someone does use it.

> 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.

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

  reply	other threads:[~2025-06-25  3:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25  2:44 [GIT PULL] Crypto Fixes for 6.16 Herbert Xu
2025-06-25  3:04 ` Eric Biggers
2025-06-25  3:14   ` Herbert Xu [this message]
2025-06-25  3:32     ` Eric Biggers
2025-06-25  3:49       ` Herbert Xu
2025-06-27  5:08 ` pr-tracker-bot
  -- strict thread matches above, loose matches on Subject: below --
2025-07-19  0:36 Herbert Xu
2025-07-19  1:34 ` pr-tracker-bot
2025-06-20  3:17 Herbert Xu
2025-06-20  6:34 ` pr-tracker-bot
2025-06-13  4:30 Herbert Xu
2025-06-13 18:04 ` pr-tracker-bot
2025-06-03  5:03 Herbert Xu
2025-06-03 16:09 ` pr-tracker-bot
2025-05-28  3:03 Herbert Xu
2025-05-28 22:16 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aFtpj5y4HtzVDChg@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox