All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	David Sterba <dsterba@suse.com>,
	Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v2 09/11] crypto: blake2s - share the "shash" API boilerplate code
Date: Fri, 18 Dec 2020 17:14:58 +0100	[thread overview]
Message-ID: <CAHmME9oW-_GXJ+nVwyiEV7wfjmzqBgqrSynnJ6xoN5UA_Nzh1Q@mail.gmail.com> (raw)
In-Reply-To: <20201217222138.170526-10-ebiggers@kernel.org>

On Thu, Dec 17, 2020 at 11:25 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> From: Eric Biggers <ebiggers@google.com>
>
> Move the boilerplate code for setkey(), init(), update(), and final()
> from blake2s_generic.ko into a new module blake2s_helpers.ko, and export
> it so that it can be used by other shash implementations of BLAKE2s.
>
> setkey() and init() are exported as-is, while update() and final() have
> a blake2s_compress_t function pointer argument added.  This allows the
> implementation of the compression function to be overridden, which is
> the only part that optimized implementations really care about.
>
> The helper functions are defined in a separate module blake2s_helpers.ko
> (rather than just than in blake2s_generic.ko) because we can't simply
> select CRYPTO_BLAKE2B from CRYPTO_BLAKE2S_X86.  Doing this selection
> unconditionally would make the library API select the shash API, while
> doing it conditionally on CRYPTO_HASH would create a recursive kconfig
> dependency on CRYPTO_HASH.  As a bonus, using a separate module also
> allows the generic implementation to be omitted when unneeded.
>
> These helper functions very closely match the ones I defined for
> BLAKE2b, except the BLAKE2b ones didn't go in a separate module yet
> because BLAKE2b isn't exposed through the library API yet.
>
> Finally, use these new helper functions in the x86 implementation of
> BLAKE2s.  (This part should be a separate patch, but unfortunately the
> x86 implementation used the exact same function names like
> "crypto_blake2s_update()", so it had to be updated at the same time.)

There's a similar situation happening with chacha20poly1305 and with
curve25519. Each of these uses a mildly different approach to how we
split things up between library and crypto api code. The _helpers.ko
is another one. There any opportunity here to take a more
unified/consistant approach? Or is shash slightly different than the
others and benefits from a third way?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	David Sterba <dsterba@suse.com>, Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v2 09/11] crypto: blake2s - share the "shash" API boilerplate code
Date: Fri, 18 Dec 2020 17:14:58 +0100	[thread overview]
Message-ID: <CAHmME9oW-_GXJ+nVwyiEV7wfjmzqBgqrSynnJ6xoN5UA_Nzh1Q@mail.gmail.com> (raw)
In-Reply-To: <20201217222138.170526-10-ebiggers@kernel.org>

On Thu, Dec 17, 2020 at 11:25 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> From: Eric Biggers <ebiggers@google.com>
>
> Move the boilerplate code for setkey(), init(), update(), and final()
> from blake2s_generic.ko into a new module blake2s_helpers.ko, and export
> it so that it can be used by other shash implementations of BLAKE2s.
>
> setkey() and init() are exported as-is, while update() and final() have
> a blake2s_compress_t function pointer argument added.  This allows the
> implementation of the compression function to be overridden, which is
> the only part that optimized implementations really care about.
>
> The helper functions are defined in a separate module blake2s_helpers.ko
> (rather than just than in blake2s_generic.ko) because we can't simply
> select CRYPTO_BLAKE2B from CRYPTO_BLAKE2S_X86.  Doing this selection
> unconditionally would make the library API select the shash API, while
> doing it conditionally on CRYPTO_HASH would create a recursive kconfig
> dependency on CRYPTO_HASH.  As a bonus, using a separate module also
> allows the generic implementation to be omitted when unneeded.
>
> These helper functions very closely match the ones I defined for
> BLAKE2b, except the BLAKE2b ones didn't go in a separate module yet
> because BLAKE2b isn't exposed through the library API yet.
>
> Finally, use these new helper functions in the x86 implementation of
> BLAKE2s.  (This part should be a separate patch, but unfortunately the
> x86 implementation used the exact same function names like
> "crypto_blake2s_update()", so it had to be updated at the same time.)

There's a similar situation happening with chacha20poly1305 and with
curve25519. Each of these uses a mildly different approach to how we
split things up between library and crypto api code. The _helpers.ko
is another one. There any opportunity here to take a more
unified/consistant approach? Or is shash slightly different than the
others and benefits from a third way?

Jason

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

  reply	other threads:[~2020-12-18 16:16 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 22:21 [PATCH v2 00/11] crypto: arm32-optimized BLAKE2b and BLAKE2s Eric Biggers
2020-12-17 22:21 ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 01/11] crypto: blake2b - rename constants for consistency with blake2s Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 02/11] crypto: blake2b - define shash_alg structs using macros Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 03/11] crypto: blake2b - export helpers for optimized implementations Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 04/11] crypto: blake2b - update file comment Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 05/11] crypto: arm/blake2b - add NEON-accelerated BLAKE2b Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 06/11] crypto: blake2s - define shash_alg structs using macros Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 07/11] crypto: x86/blake2s " Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 08/11] crypto: blake2s - remove unneeded includes Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 09/11] crypto: blake2s - share the "shash" API boilerplate code Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-18 16:14   ` Jason A. Donenfeld [this message]
2020-12-18 16:14     ` Jason A. Donenfeld
2020-12-18 20:08     ` Eric Biggers
2020-12-18 20:08       ` Eric Biggers
2020-12-19  0:01       ` Jason A. Donenfeld
2020-12-19  0:01         ` Jason A. Donenfeld
2020-12-22  8:55         ` Eric Biggers
2020-12-22  8:55           ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 10/11] crypto: arm/blake2s - add ARM scalar optimized BLAKE2s Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-17 22:21 ` [PATCH v2 11/11] wireguard: Kconfig: select CRYPTO_BLAKE2S_ARM Eric Biggers
2020-12-17 22:21   ` Eric Biggers
2020-12-18 16:02   ` Jason A. Donenfeld
2020-12-18 16:02     ` Jason A. Donenfeld
2020-12-18 16:30 ` [PATCH v2 00/11] crypto: arm32-optimized BLAKE2b and BLAKE2s Ard Biesheuvel
2020-12-18 16:30   ` Ard Biesheuvel

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=CAHmME9oW-_GXJ+nVwyiEV7wfjmzqBgqrSynnJ6xoN5UA_Nzh1Q@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=paulcrowley@google.com \
    /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.