Join our Newsletter — 33% off our NHI Course

CO-RE

Compile Once Run Everywhere is an eBPF portability approach that lets one compiled program run across different kernel versions and configurations. It relies on BTF metadata to adapt to kernel differences, reducing rework and making eBPF deployments easier to operationalise at scale.

Expanded Definition

CO-RE, short for Compile Once Run Everywhere, is an eBPF portability model that aims to make one compiled program work across kernel variants without per-kernel rewrites. It does this by pairing the program with BTF metadata, which describes kernel types and layouts in a machine-readable form.

In practice, CO-RE matters because kernel structures and field offsets change over time, especially across distributions, backports, and vendor-tuned builds. A portable eBPF program can adjust to those differences at load time, which reduces version-specific code paths and lowers the maintenance burden for telemetry, observability, and enforcement tooling.

The boundary to keep in mind is that CO-RE is not generic “write once, forget forever” portability. It depends on the target kernel exposing the right BTF information and on the program being written in a way that can tolerate layout changes. Where BTF is missing or incomplete, portability drops and fallback logic becomes necessary.

Examples and Use Cases

  • An observability agent can ship one eBPF object file to multiple Linux fleets and still resolve kernel field changes through BTF-aware relocation.
  • A host intrusion detection sensor can attach to system events across mixed kernel versions without maintaining a separate build for each environment.
  • A network or process telemetry pipeline can standardise deployment across container hosts, bare metal, and cloud instances while avoiding repeated recompilation.
  • A platform team can reduce release friction by treating kernel compatibility as a load-time concern rather than a build-time matrix problem.

The tradeoff is operational rather than conceptual: CO-RE reduces recompile churn, but it does not eliminate the need to validate behaviour on the exact kernels you run. The safest teams still test against representative kernel families before broad rollout.

Security Implications

CO-RE improves security tooling consistency by making it easier to deploy the same eBPF-based control or sensor across heterogeneous Linux environments. That consistency matters because security coverage often breaks down when teams avoid upgrading or disable telemetry on “odd” kernel versions.

When CO-RE is misunderstood, teams may assume portability guarantees that are stronger than reality. If BTF data is absent, stale, or mismatched, the program may fail to load, attach to the wrong fields, or produce incomplete telemetry. In security tooling, that can mean blind spots rather than obvious errors.

Another practical consequence is governance drift. If one environment silently falls back to a non-CO-RE path, operators can end up with uneven detection quality across clusters. A useful practitioner signal is any deployment that succeeds technically but no longer produces the same event coverage, field extraction, or policy outcome as the validated baseline.

Security, Operational and Governance Implications

CO-RE is important because it changes how teams operationalise kernel-resident security capabilities at scale. Instead of maintaining separate builds for every kernel line, teams can converge on one program and focus review effort on the program logic, attachment points, and kernel feature assumptions.

That has governance value: it reduces configuration sprawl, simplifies rollout controls, and makes it easier to reason about what is actually deployed. It also encourages tighter version discipline around BTF availability, kernel feature parity, and test coverage across the fleet.

For practitioners, the main lesson is that portability is only useful when it remains observable. A CO-RE pipeline should be treated as a controlled deployment path, not a magical compatibility layer, because the security outcome depends on whether the program still sees the kernel state it was designed to inspect.