From: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
To: "Blaise Boscaccy" <bboscaccy@linux.microsoft.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Mickaël Salaün" <mic@digikod.net>,
"Günther Noack" <gnoack@google.com>,
"Dr. David Alan Gilbert" <linux@treblig.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
James.Bottomley@HansenPartnership.com, dhowells@redhat.com,
linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: [RFC 00/11] Reintroduce Hornet LSM
Date: Wed, 10 Dec 2025 18:11:55 -0800 [thread overview]
Message-ID: <20251211021257.1208712-1-bboscaccy@linux.microsoft.com> (raw)
This patch series introduces the next iteration of the Hornet LSM.
Hornet’s goal is to provide a secure and extensible in-kernel
signature verification mechanism for eBPF programs. The purpose of
this RFC is to gather feedback on the LSM design and the newly added
downstream LSM hooks, as well as gauge community sentiment. The
userspace tooling still needs some refinement. The currently accepted
loader-plus-map signature verification scheme, mandated by Alexei and
KP, is simple to implement and generally acceptable if users and
administrators are satisfied with it. However, verifying both the
loader and the maps offers additional benefits beyond verifying the
loader alone:
1. Security and Audit Integrity
A key advantage is that the LSM hook for authorizing BPF program loads
can operate after signature verification. This ensures:
* Access control decisions are based on verified signature status.
* Accurate system state measurement and logging.
* Log entries claiming a verified signature are truthful, avoiding
misleading records where only the loader was verified while the actual
BPF program verification occurs later without logging.
2. TOCTOU Attack Prevention
The current map hash implementation may be vulnerable to a TOCTOU
attack because it allows unfrozen maps to cache a previously
calculated hash. The accepted “trusted loader” scheme cannot detect
this and may permit loading altered maps.
This approach addresses concerns from users who require strict audit
trails and verification guarantees, especially in security-sensitive
environments. Map hashes for extended verification are passed via the
existing PKCS#7 UAPI and verified by the crypto subsystem. Hornet then
calculates the program’s verification state (full, partial, bad, etc.)
and invokes a new downstream LSM hook to delegate policy decisions.
Blaise Boscaccy (4):
security: Hornet LSM
hornet: Introduce gen_sig
hornet: Add a light skeleton data extractor scripts
selftests/hornet: Add a selftest for the Hornet LSM
James Bottomley (6):
oid_registry: allow arbitrary size OIDs
certs: break out pkcs7 check into its own function
crypto: pkcs7: add flag for validated trust on a signed info block
crypto: pkcs7: allow pkcs7_digest() to be called from pkcs7_trust
crypto: pkcs7: add ability to extract signed attributes by OID
crypto: pkcs7: add tests for pkcs7_get_authattr
Paul Moore (1):
lsm: framework for BPF integrity verification
Documentation/admin-guide/LSM/Hornet.rst | 38 ++
Documentation/admin-guide/LSM/index.rst | 1 +
MAINTAINERS | 9 +
certs/system_keyring.c | 76 ++--
crypto/asymmetric_keys/Makefile | 4 +-
crypto/asymmetric_keys/pkcs7_aa.asn1 | 18 +
crypto/asymmetric_keys/pkcs7_key_type.c | 42 +-
crypto/asymmetric_keys/pkcs7_parser.c | 87 ++++
crypto/asymmetric_keys/pkcs7_parser.h | 4 +
crypto/asymmetric_keys/pkcs7_trust.c | 9 +
crypto/asymmetric_keys/pkcs7_verify.c | 13 +-
include/crypto/pkcs7.h | 4 +
include/linux/lsm_hook_defs.h | 5 +
include/linux/oid_registry.h | 3 +
include/linux/security.h | 25 ++
include/linux/verification.h | 2 +
include/uapi/linux/lsm.h | 1 +
lib/build_OID_registry | 26 +-
scripts/Makefile | 1 +
scripts/hornet/Makefile | 5 +
scripts/hornet/extract-insn.sh | 27 ++
scripts/hornet/extract-map.sh | 27 ++
scripts/hornet/extract-skel.sh | 27 ++
scripts/hornet/gen_sig.c | 392 +++++++++++++++++++
scripts/hornet/write-sig.sh | 27 ++
security/Kconfig | 3 +-
security/Makefile | 1 +
security/hornet/Kconfig | 11 +
security/hornet/Makefile | 7 +
security/hornet/hornet.asn1 | 13 +
security/hornet/hornet_lsm.c | 201 ++++++++++
security/security.c | 75 +++-
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/hornet/Makefile | 63 +++
tools/testing/selftests/hornet/loader.c | 21 +
tools/testing/selftests/hornet/trivial.bpf.c | 33 ++
36 files changed, 1253 insertions(+), 49 deletions(-)
create mode 100644 Documentation/admin-guide/LSM/Hornet.rst
create mode 100644 crypto/asymmetric_keys/pkcs7_aa.asn1
create mode 100644 scripts/hornet/Makefile
create mode 100755 scripts/hornet/extract-insn.sh
create mode 100755 scripts/hornet/extract-map.sh
create mode 100755 scripts/hornet/extract-skel.sh
create mode 100644 scripts/hornet/gen_sig.c
create mode 100755 scripts/hornet/write-sig.sh
create mode 100644 security/hornet/Kconfig
create mode 100644 security/hornet/Makefile
create mode 100644 security/hornet/hornet.asn1
create mode 100644 security/hornet/hornet_lsm.c
create mode 100644 tools/testing/selftests/hornet/Makefile
create mode 100644 tools/testing/selftests/hornet/loader.c
create mode 100644 tools/testing/selftests/hornet/trivial.bpf.c
--
2.52.0
next reply other threads:[~2025-12-11 2:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 2:11 Blaise Boscaccy [this message]
2025-12-11 2:11 ` [RFC 01/11] lsm: framework for BPF integrity verification Blaise Boscaccy
2025-12-11 2:11 ` [RFC 02/11] oid_registry: allow arbitrary size OIDs Blaise Boscaccy
2025-12-11 2:11 ` [RFC 03/11] certs: break out pkcs7 check into its own function Blaise Boscaccy
2025-12-11 2:11 ` [RFC 04/11] crypto: pkcs7: add flag for validated trust on a signed info block Blaise Boscaccy
2025-12-11 2:12 ` [RFC 05/11] crypto: pkcs7: allow pkcs7_digest() to be called from pkcs7_trust Blaise Boscaccy
2025-12-11 2:12 ` [RFC 06/11] crypto: pkcs7: add ability to extract signed attributes by OID Blaise Boscaccy
2025-12-11 16:44 ` Randy Dunlap
2025-12-11 2:12 ` [RFC 07/11] crypto: pkcs7: add tests for pkcs7_get_authattr Blaise Boscaccy
2025-12-11 2:12 ` [RFC 08/11] security: Hornet LSM Blaise Boscaccy
2025-12-11 20:07 ` Randy Dunlap
2025-12-12 21:00 ` Fan Wu
2025-12-11 2:12 ` [RFC 09/11] hornet: Introduce gen_sig Blaise Boscaccy
2025-12-11 2:12 ` [RFC 10/11] hornet: Add a light skeleton data extractor scripts Blaise Boscaccy
2025-12-11 2:12 ` [RFC 11/11] selftests/hornet: Add a selftest for the Hornet LSM Blaise Boscaccy
2025-12-12 9:45 ` [RFC 04/11] crypto: pkcs7: add flag for validated trust on a signed info block David Howells
2025-12-13 5:50 ` James Bottomley
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=20251211021257.1208712-1-bboscaccy@linux.microsoft.com \
--to=bboscaccy@linux.microsoft.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=gnoack@google.com \
--cc=jmorris@namei.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux@treblig.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.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;
as well as URLs for NNTP newsgroup(s).