From: Eric Biggers <ebiggers@kernel.org>
To: "Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>
Cc: Jens Axboe <axboe@kernel.dk>,
drbd-dev@lists.linux.dev, linux-kernel@vger.kernel.org,
Lars Ellenberg <lars.ellenberg@linbit.com>,
Philipp Reisner <philipp.reisner@linbit.com>,
linux-block@vger.kernel.org
Subject: Re: [PATCH] drbd: select CRYPTO and CRYPTO_HASH
Date: Wed, 11 Nov 2026 13:22:45 -0800 [thread overview]
Message-ID: <20261111212245.GB41158@quark> (raw)
In-Reply-To: <20261111083505.3998706-1-christoph.boehmwalder@linbit.com>
On Wed, Nov 11, 2026 at 09:35:05AM +0100, Christoph Böhmwalder wrote:
> DRBD uses the shash API for the data integrity, online verify and
> checksum-based resync algorithms and for peer authentication, but
> BLK_DEV_DRBD does not select the crypto core. With CRYPTO=n, a kernel
> with DRBD built in does not link:
>
> ld: drbd_sender.c:(.text+0x137f): undefined reference to `crypto_shash_finup'
> ld: drbd_receiver.c:(.text+0x58f): undefined reference to `crypto_alloc_shash'
>
> Select CRYPTO and CRYPTO_HASH.
>
> Fixes: b411b3637fa7 ("The DRBD driver")
> Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Looks fine for now, but you should consider what algorithms DRBD
actually needs and consider switching to the library APIs for those
instead of crypto_shash. Presumably not more than a handful are
actually used in practice with DRBD, and you don't really need to keep
"supporting" MD4, Whirlpool, RIPEMD, CMAC-SM4, etc.?
The "pass arbitrary string from userspace to crypto_alloc_*()" strategy
has been problematic for other kernel features using it. For one, it
gives access to algorithms that are obsolete, insecure, redundant or
make no sense for the use case. And it makes it more difficult to
remove unused algorithms from the crypto API, since it makes it harder
to prove that they are in fact unused.
Note that the crypto_shash API is also somewhat inefficient and
difficult to use correctly, even though it's better than crypto_ahash.
(And the DRBD driver got it wrong, so just FYI, you should expect fixes
if you keep using it...).
- Eric
prev parent reply other threads:[~2026-11-11 21:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 8:35 Christoph Böhmwalder
2026-11-11 21:22 ` Eric Biggers [this message]
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=20261111212245.GB41158@quark \
--to=ebiggers@kernel.org \
--cc=axboe@kernel.dk \
--cc=christoph.boehmwalder@linbit.com \
--cc=drbd-dev@lists.linux.dev \
--cc=lars.ellenberg@linbit.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=philipp.reisner@linbit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®