Re: [RFC 00/11] Reintroduce Hornet LSM

Re: [RFC 00/11] Reintroduce Hornet LSM

[Paul Moore]

On Mon, Dec 15, 2025 at 12:26 PM ryan foster <foster.ryan.r@gmail.com> wrote:
>
> Hi all,
>
> I want to confirm I understand the current semantics, and specific issues this series is addressing.

I don't want to speak for Blaise (or James for that matter), but my
understanding is that Hornet is focused on ensuring BPF program
integrity at load time; similar to KP's signature scheme which has
recently found its way into Linus tree.  Where KP's and Blaise's
scheme differ is in how they perform the integrity checks.

-- 
paul-moore.com

Re: [RFC 00/11] Reintroduce Hornet LSM

[Blaise Boscaccy]

ryan foster <foster.ryan.r@gmail.com> writes:

> Hi all,
>

Hi Ryan,

> I want to confirm I understand the current semantics, and specific issues
> this series is addressing.
>
> In the signed BPF two step flow, the LSM makes decisions using what is
> known at the time of run hooks.  At load time, the only clear fact is "the
> loader is signed".  However, if we really want integrity for "the final
> program that will execute after relocation, and any inputs as part of the
> contract, matches what was signed".  The fact exists after loader runs, so
> the kernel could end up allowing and auditing based on the signed loader,
> even though it cannot yet truthfully say the runnable payload has been
> verified.
>

Correct.

> If this is the right understanding, perhaps we could consider a design that
> moves enforcement to the moment the program becomes effective. E.g.  Load
> can create a program object, but it is inert by default.  The kernel should
> only allow attach or link creation if the kernel has already recorded a
> verified record of the final relocated instruction stream plus
> referenced state for inputs, is included in the "integrity contract".
>
> If the referenced state is mutable, then either state must be frozen before
> the contract is verified, or any mutation must invalidate verified and
> force re-verification and a new policy decision. Otherwise the state is
> susceptible to TOCTOU issues.
>
> Is this the semantic goal Hortnet is aiming for, and is attack or link
> creation the intended enforcement point for the "cannot become effective
> until verified" rule, instead of trying to make a load time hook represent
> final payload verification?
>
> Thanks
>
> Regard, Ryan


The semantic goal for Hornet is to validate the provenance and integrity
of all the user-generated inputs when they are loaded into the kernel,
in order to allow users to make intelligent security decisions based
on that. IMO, attaching and linking are orthogonal run-time policy issues
that are seperate from provenance and data integrity concerns.

Allowing or disallowing linking and attaching based on the completeness of
signature validation does make sense. That kind of decision would
probably be handled by selinux, IPE, or a custom BPF LSM program most
likely though. 

-blaise

[RFC 00/11] Reintroduce Hornet LSM

[Blaise Boscaccy]

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

Re: [RFC 00/11] Reintroduce Hornet LSM

[Ryan Foster]

From: Ryan <foster.ryan.r@gmail.com>

Hi all,

I want to confirm I understand the current semantics, and specific issues this series is addressing.  

In the signed BPF two step flow, the LSM makes decisions using what is known at the time of run hooks.  At load time, the only clear fact is "the loader is signed".  However, if we really want integrity for "the final program that will execute after relocation, and any inputs as part of the contract, matches what was signed".  The fact exists after loader runs, so the kernel could end up allowing and auditing based on the signed loader, even though it cannot yet truthfully say the runnable payload has been verified.

If this is the right understanding, perhaps we could consider a design that moves enforcement to the moment the program becomes effective. E.g.  Load can create a program object, but it is inert by default.  The kernel should only allow attach or link creation if the kernel has already recorded a verified record of the final relocated instruction stream plus referenced state for inputs, is included in the "integrity contract".  

If the referenced state is mutable, then either state must be frozen before the contract is verified, or any mutation must invalidate verified and force re-verification and a new policy decision. Otherwise the state is susceptible to TOCTOU issues.

Is this the semantic goal Hornet is aiming for, and is attach or link creation the intended enforcement point for the "cannot become effective until verified" rule, instead of trying to make a load time hook represent final payload verification? 

Thanks,
Ryan