All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-crypto@vger.kernel.org, fsverity@lists.linux.dev,
	dm-devel@lists.linux.dev,
	Herbert Xu <herbert@gondor.apana.org.au>,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org,
	Sami Tolvanen <samitolvanen@google.com>,
	Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH v4 1/8] crypto: shash - add support for finup_mb
Date: Tue, 4 Jun 2024 12:25:42 -0700	[thread overview]
Message-ID: <20240604192542.GD1566@sol.localdomain> (raw)
In-Reply-To: <CAMj1kXHVbVhydU60zzUc8a-jVkboRz1pz0TW7Sx_5N_AvdhZdA@mail.gmail.com>

On Tue, Jun 04, 2024 at 08:55:48PM +0200, Ard Biesheuvel wrote:
> >
> > This patch takes a new approach of just adding an API
> > crypto_shash_finup_mb() that synchronously computes the hash of multiple
> > equal-length messages, starting from a common state that represents the
> > (possibly empty) common prefix shared by the messages.
> >
> 
> This is an independent optimization, right? This could be useful even
> more sequential hashing, and is not a fundamental aspect of parallel
> hashing?

If you're referring to the part about using a common starting state, that's not
an independent optimization.  Only multibuffer hashing processes multiple
messages in one call and therefore has an opportunity to share a starting
shash_desc for finup.  This isn't just an optimization but it also makes the
multibuffer hashing API and its implementation much simpler.

With single-buffer there has to be one shash_desc per message as usual.

If you're asking if crypto_shash_finup_mb() can be used even without multibuffer
hashing support, the answer is yes.  This patchset makes crypto_shash_finup_mb()
fall back to crypto_shash_finup() as needed, and this is used by fsverity and
dm-verity to have one code path that uses crypto_shash_finup_mb() instead of
separate code paths that use crypto_shash_finup_mb() and crypto_shash_finup().
This just makes things a bit simpler and isn't an optimization; note that the
fallback has to copy the shash_desc for each message beyond the first.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-crypto@vger.kernel.org, fsverity@lists.linux.dev,
	dm-devel@lists.linux.dev,
	Herbert Xu <herbert@gondor.apana.org.au>,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org,
	Sami Tolvanen <samitolvanen@google.com>,
	Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH v4 1/8] crypto: shash - add support for finup_mb
Date: Tue, 4 Jun 2024 12:25:42 -0700	[thread overview]
Message-ID: <20240604192542.GD1566@sol.localdomain> (raw)
In-Reply-To: <CAMj1kXHVbVhydU60zzUc8a-jVkboRz1pz0TW7Sx_5N_AvdhZdA@mail.gmail.com>

On Tue, Jun 04, 2024 at 08:55:48PM +0200, Ard Biesheuvel wrote:
> >
> > This patch takes a new approach of just adding an API
> > crypto_shash_finup_mb() that synchronously computes the hash of multiple
> > equal-length messages, starting from a common state that represents the
> > (possibly empty) common prefix shared by the messages.
> >
> 
> This is an independent optimization, right? This could be useful even
> more sequential hashing, and is not a fundamental aspect of parallel
> hashing?

If you're referring to the part about using a common starting state, that's not
an independent optimization.  Only multibuffer hashing processes multiple
messages in one call and therefore has an opportunity to share a starting
shash_desc for finup.  This isn't just an optimization but it also makes the
multibuffer hashing API and its implementation much simpler.

With single-buffer there has to be one shash_desc per message as usual.

If you're asking if crypto_shash_finup_mb() can be used even without multibuffer
hashing support, the answer is yes.  This patchset makes crypto_shash_finup_mb()
fall back to crypto_shash_finup() as needed, and this is used by fsverity and
dm-verity to have one code path that uses crypto_shash_finup_mb() instead of
separate code paths that use crypto_shash_finup_mb() and crypto_shash_finup().
This just makes things a bit simpler and isn't an optimization; note that the
fallback has to copy the shash_desc for each message beyond the first.

- Eric

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-06-04 19:25 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03 18:37 [PATCH v4 0/8] Optimize dm-verity and fsverity using multibuffer hashing Eric Biggers
2024-06-03 18:37 ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 1/8] crypto: shash - add support for finup_mb Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-04 18:55   ` Ard Biesheuvel
2024-06-04 18:55     ` Ard Biesheuvel
2024-06-04 19:25     ` Eric Biggers [this message]
2024-06-04 19:25       ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 2/8] crypto: testmgr - generate power-of-2 lengths more often Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 3/8] crypto: testmgr - add tests for finup_mb Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 4/8] crypto: x86/sha256-ni - add support " Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 5/8] crypto: arm64/sha256-ce " Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-04 19:00   ` Ard Biesheuvel
2024-06-04 19:00     ` Ard Biesheuvel
2024-06-03 18:37 ` [PATCH v4 6/8] fsverity: improve performance by using multibuffer hashing Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-04  9:37   ` Herbert Xu
2024-06-04  9:37     ` Herbert Xu
2024-06-04 18:42     ` Eric Biggers
2024-06-04 18:42       ` Eric Biggers
2024-06-05  9:19       ` Herbert Xu
2024-06-05  9:19         ` Herbert Xu
2024-06-05  9:22         ` Herbert Xu
2024-06-05  9:22           ` Herbert Xu
2024-06-05  9:46           ` Herbert Xu
2024-06-05  9:46             ` Herbert Xu
2024-06-05 19:14             ` Eric Biggers
2024-06-05 19:14               ` Eric Biggers
2024-06-06  2:00               ` Herbert Xu
2024-06-06  2:00                 ` Herbert Xu
2024-06-06  5:28                 ` Eric Biggers
2024-06-06  5:28                   ` Eric Biggers
2024-06-06  5:41                   ` Herbert Xu
2024-06-06  5:41                     ` Herbert Xu
2024-06-06  6:58                     ` Ard Biesheuvel
2024-06-06  6:58                       ` Ard Biesheuvel
2024-06-06  7:34                       ` Herbert Xu
2024-06-06  7:34                         ` Herbert Xu
2024-06-06  7:55                         ` Ard Biesheuvel
2024-06-06  7:55                           ` Ard Biesheuvel
2024-06-06  8:08                           ` Herbert Xu
2024-06-06  8:08                             ` Herbert Xu
2024-06-06  8:33                             ` Ard Biesheuvel
2024-06-06  8:33                               ` Ard Biesheuvel
2024-06-06  9:15                               ` Herbert Xu
2024-06-06  9:15                                 ` Herbert Xu
2024-06-10 16:42                                 ` Eric Biggers
2024-06-10 16:42                                   ` Eric Biggers
2024-06-11 15:21                                   ` Herbert Xu
2024-06-11 15:21                                     ` Herbert Xu
2024-06-11 15:39                                     ` Herbert Xu
2024-06-11 15:39                                       ` Herbert Xu
2024-06-11 20:32                                       ` Eric Biggers
2024-06-11 15:46                                     ` Ard Biesheuvel
2024-06-11 15:46                                       ` Ard Biesheuvel
2024-06-11 15:51                                       ` Herbert Xu
2024-06-11 15:51                                         ` Herbert Xu
2024-06-11 20:18                                     ` Eric Biggers
2024-06-05 18:58         ` Eric Biggers
2024-06-05 18:58           ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 7/8] dm-verity: hash blocks with shash import+finup when possible Eric Biggers
2024-06-03 18:37   ` Eric Biggers
2024-06-03 18:37 ` [PATCH v4 8/8] dm-verity: improve performance by using multibuffer hashing Eric Biggers
2024-06-03 18:37   ` Eric Biggers

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=20240604192542.GD1566@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=dm-devel@lists.linux.dev \
    --cc=fsverity@lists.linux.dev \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=samitolvanen@google.com \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.