[RFC 00/11] Reintroduce Hornet LSM

[ryan foster]

Hi Paul, Blaise,

Thanks for clarifying, that matches my understanding.

My read is Hornet's semantic goal is load-time provenance and
integrity: validate the user-generated inputs once the kernel has
constructed the final in-kernel program instance (post-relocation,
with any integrity-relevant referenced inputs accounted for), and
record that result so LSM/policy can make decisions based on a fact
the kernel can truthfully assert.

Attaching and linking are separate runtime policy/capability
questions. It makes sense that SELinux, IPE, or a BPF LSM program
could choose to gate attach/link based on whether Hornet recorded the
program as verified, but that enforcement is orthogonal to Hornet's
core integrity/provenance objective.

Thanks


On Thu, Dec 18, 2025 at 9:39 AM ryan foster <foster.ryan.r at gmail.com> wrote:
>
> Hi Paul, Blaise,
>
> Thanks for clarifying, that matches my understanding.
>
> My read is Hornet's semantic goal is load-time provenance and integrity: validate the user-generated inputs once the kernel has constructed the final in-kernel program instance (post-relocation, with any integrity-relevant referenced inputs accounted for), and record that result so LSM/policy can make decisions based on a fact the kernel can truthfully assert.
>
> Attaching and linking are separate runtime policy/capability questions. It makes sense that SELinux, IPE, or a BPF LSM program could choose to gate attach/link based on whether Hornet recorded the program as verified, but that enforcement is orthogonal to Hornet's core integrity/provenance objective.
>
> Thanks
>
>
> On Wed, Dec 17, 2025 at 11:33 AM Blaise Boscaccy <bboscaccy at linux.microsoft.com> wrote:
>>
>> ryan foster <foster.ryan.r at 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