From: Daniel Borkmann <daniel@iogearbox.net>
To: memxor@gmail.com
Cc: brauner@kernel.org, kpsingh@kernel.org, ast@kernel.org,
john.fastabend@gmail.com, a.s.protopopov@gmail.com,
bpf@vger.kernel.org, dhowells@redhat.com, jarkko@kernel.org,
keyrings@vger.kernel.org
Subject: [PATCH bpf-next v2 04/11] bpftool: Support ML-DSA program signing
Date: Tue, 25 Aug 2026 16:25:23 +0200 [thread overview]
Message-ID: <20260825142530.1329706-5-daniel@iogearbox.net> (raw)
In-Reply-To: <20260825142530.1329706-1-daniel@iogearbox.net>
Add bpftool support for ML-DSA program signing and drop the flag for
ML-DSA keys on affected OpenSSL versions, the same way as commit
0ad9a71933e7 ("modsign: Enable ML-DSA module signing").
Two small differences to the latter: sign-file.c for modules takes its
digest from the command line whereas bpftool has no such knob, so the
digest is pinned to SHA-512 for ML-DSA keys. ML-DSA ignores the CMS
digest and hashes the message itself, but with signedAttrs back in
place they are what gets signed and only SHA-512 is permitted there.
Also, an ML-DSA-87 signature is 4627 bytes on its own, so the blob does
not fit into the 4 KiB of MAX_SIG_SIZE anymore and signing would fail
otherwise. Bump to 16 KiB. MAX_SIG_SIZE only sizes the buffer for
what bpftool itself emits (unrelated to BPF_PROG_MAX_SIGNATURE_SIZE).
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
tools/bpf/bpftool/main.h | 2 +-
tools/bpf/bpftool/sign.c | 22 +++++++++++++++++++---
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index 78b6e0ebb85d..9315a1db1f7c 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -57,7 +57,7 @@ static inline void *u64_to_ptr(__u64 ptr)
})
#define ERR_MAX_LEN 1024
-#define MAX_SIG_SIZE 4096
+#define MAX_SIG_SIZE 16384
#define BPF_TAG_FMT "%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
diff --git a/tools/bpf/bpftool/sign.c b/tools/bpf/bpftool/sign.c
index 88726a6db6d0..1b5502f48add 100644
--- a/tools/bpf/bpftool/sign.c
+++ b/tools/bpf/bpftool/sign.c
@@ -130,6 +130,9 @@ __u32 register_session_key(const char *key_der_path)
int bpftool_prog_sign(struct bpf_load_and_run_opts *opts)
{
+ unsigned int signer_flags = CMS_NOCERTS | CMS_BINARY | CMS_NOSMIMECAP |
+ CMS_USE_KEYID | CMS_NOATTR;
+ const EVP_MD *cms_digest = EVP_sha256();
BIO *bd_in = NULL, *bd_out = NULL;
EVP_PKEY *private_key = NULL;
CMS_ContentInfo *cms = NULL;
@@ -167,6 +170,21 @@ int bpftool_prog_sign(struct bpf_load_and_run_opts *opts)
goto cleanup;
}
+#if OPENSSL_VERSION_NUMBER >= 0x30000000L && OPENSSL_VERSION_NUMBER < 0x40000000L
+ if (EVP_PKEY_is_a(private_key, "ML-DSA-44") ||
+ EVP_PKEY_is_a(private_key, "ML-DSA-65") ||
+ EVP_PKEY_is_a(private_key, "ML-DSA-87")) {
+ /*
+ * ML-DSA + CMS_NOATTR is not supported before openssl-4.0, so
+ * fall back to signedAttrs. ML-DSA does its own hashing and
+ * ignores the CMS digest, except when signedAttrs are used,
+ * where only SHA-512 is permitted.
+ */
+ signer_flags &= ~CMS_NOATTR;
+ cms_digest = EVP_sha512();
+ }
+#endif
+
cms = CMS_sign(NULL, NULL, NULL, NULL,
CMS_NOCERTS | CMS_PARTIAL | CMS_BINARY | CMS_DETACHED |
CMS_STREAM);
@@ -175,9 +193,7 @@ int bpftool_prog_sign(struct bpf_load_and_run_opts *opts)
goto cleanup;
}
- if (!CMS_add1_signer(cms, x509, private_key, EVP_sha256(),
- CMS_NOCERTS | CMS_BINARY | CMS_NOSMIMECAP |
- CMS_USE_KEYID | CMS_NOATTR)) {
+ if (!CMS_add1_signer(cms, x509, private_key, cms_digest, signer_flags)) {
err = -EINVAL;
goto cleanup;
}
--
2.43.0
next prev parent reply other threads:[~2026-08-25 14:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 14:25 [PATCH bpf-next v2 00/11] BPF keyring and signed loader ML-DSA support Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 01/11] bpf: Add a bpf keyring for program signature validation Daniel Borkmann
2026-08-25 14:39 ` sashiko-bot
2026-08-25 14:25 ` [PATCH bpf-next v2 02/11] bpf: Refuse caller-supplied keyrings when the bpf one is active Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 03/11] bpf: Raise the bound on a program's signature size Daniel Borkmann
2026-08-25 14:25 ` Daniel Borkmann [this message]
2026-08-25 14:36 ` [PATCH bpf-next v2 04/11] bpftool: Support ML-DSA program signing sashiko-bot
2026-08-25 14:25 ` [PATCH bpf-next v2 05/11] selftests/bpf: Add a test for the sealed bpf keyring Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 06/11] selftests/bpf: Rebuild signed lskels when signing key changes Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 07/11] selftests/bpf: Rename the verify_sig_setup.sh setup into setup-rsa Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 08/11] selftests/bpf: Add an end-to-end ML-DSA signed loader test Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 09/11] selftests/bpf: Allow appending to guest kernel cmdline in vmtest.sh Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 10/11] selftests/bpf: Add tests for bpf keyring in signed loader Daniel Borkmann
2026-08-25 14:25 ` [PATCH bpf-next v2 11/11] Documentation/bpf: Document the bpf keyring and improve examples Daniel Borkmann
2026-08-28 1:38 ` [PATCH bpf-next v2 00/11] BPF keyring and signed loader ML-DSA support Jarkko Sakkinen
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=20260825142530.1329706-5-daniel@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=a.s.protopopov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=kpsingh@kernel.org \
--cc=memxor@gmail.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