Lines Matching full:program
16 A signed BPF program lets the kernel establish that the bytecode being loaded
18 the kernel does not *require* signatures - an unsigned program loads exactly as
26 privileges (``CAP_BPF`` and any program-type-specific capability, subject to
28 checked by the verifier like any other program. A valid signature establishes
32 The hard part is *what* gets signed. A naive scheme would sign a program's
36 signed. Between the two, libbpf and the kernel rewrite the program:
52 actually loads - which is why a program cannot simply be signed and loaded
58 The solution is to move that setup work *into* a small BPF program - the
61 emits a ``BPF_PROG_TYPE_SYSCALL`` program whose body performs the bpf() syscalls
77 Why the loader is signable when the program is not
103 signature can be checked" to "after a trusted program runs" - which is exactly
111 accessed by a program whose digest matches that hash. The verifier enforces
112 ``map->excl_prog_sha == prog->digest`` for every map a program uses, so the
114 or mutated by another program.
120 map read-only to the loader program itself, which still writes created file
136 has resolved the ``fd_array`` entries into the program's ``used_maps``. The
137 maps folded into the signature are therefore the very objects the program
150 A signed program therefore takes one of exactly two shapes, both fully
155 yields ``BPF_SIG_VERIFIED`` and the program loads. This is the ordinary case
156 for a directly-loaded signed program with no separate payload; it is *not*
161 There is no third shape: a non-exclusive map in a signed program's ``fd_array``
176 verifier tries to bind it. A BTF is refused outright for a signed program - a
179 above this keeps the verdict binary: a signed program cannot use a map its
182 signed program cannot use one at all.
187 A program is either unsigned or fully verified - there is no intermediate
198 *and* the frozen contents of every exclusive map the program uses:
200 - For an ordinary, directly-loaded signed program the instructions are the whole
209 program and everything the signature is responsible for are authentic, which is
219 keyring fields live in ``struct bpf_prog_aux``, so a BPF LSM program can read
224 and the existing ``security_bpf_prog()`` observes a program that has fully
233 hook can see whether, and how strongly, the program was signed, which keyring
240 keyring, restrict which token/credentials may load BPF, apply per-program-type
247 a load at this point lets it *proceed*; it does not guarantee the program will
248 load. A validly signed program can still be rejected afterwards on two
249 independent grounds: the verifier may reject it like any other program (unsafe
253 returned. Only after the program has fully loaded, at the next hook
318 fact. To *act on* a program that has successfully and fully loaded, use the
324 - the program has an id (``prog->aux->id``), so it can be recorded or correlated
326 - ``verdict == BPF_SIG_VERIFIED`` *here* means **fully** verified - a program
334 other paths that mint a new program fd - notably ``bpf_prog_get_fd_by_id()`` -
335 not just on a fresh load. Because the program already has its id here, an LSM
337 the load; a later sighting of the same id is just another fd to a program that
368 /* First sighting == this program just loaded; id is valid here. */
373 /* ... newly-loaded verified-program action, e.g. record r.id ... */
379 keyring). The kernel then guarantees that any program which actually loads with
398 verification aborts the load - so a program that loads successfully with a
404 Classified purely from ``keyring_id`` whenever the program is signed:
407 ``BPF_SIG_KEYRING_NONE`` for an unsigned program.
476 Array of map (and module BTF) file descriptors bound to the program.
485 SHA-256 digest of the program permitted to access this (exclusive) map. This
488 by the program signature.