4b6817381b
Benchmark image — build + push to ECR (any adapter) / build + push (push) Waiting to run
CI / quality (ubuntu-latest) (push) Waiting to run
CI / test (tools-runtime) (push) Waiting to run
CI / test (e2e-general) (push) Waiting to run
CI / test (cli-runtime) (push) Waiting to run
CI / test (e2e-provider-and-openclaw) (push) Waiting to run
CI / test (integrations-and-misc) (push) Waiting to run
CI / coverage-report (push) Blocked by required conditions
CI / test-kubernetes (push) Waiting to run
CI / should-run-thorough (push) Waiting to run
CI / test-thorough (cloudwatch-demo) (push) Blocked by required conditions
CI / test-thorough (flink-ecs) (push) Blocked by required conditions
CI / test-thorough (upstream-lambda) (push) Blocked by required conditions
CI / test-thorough (prefect-ecs-fargate) (push) Blocked by required conditions
CodeQL / Analyze (python) (push) Waiting to run
Release / build-binaries (zip, opensre.exe, onefile, windows-latest, windows-x64) (push) Blocked by required conditions
Release / publish-release (push) Blocked by required conditions
Release / publish-main-release (push) Blocked by required conditions
Release / prepare (push) Waiting to run
Release / verify (push) Blocked by required conditions
Release / build-python-dist (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, macos-15-intel, darwin-x64) (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, macos-latest, darwin-arm64) (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, ubuntu-22.04, linux-x64) (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, ubuntu-22.04-arm, linux-arm64) (push) Blocked by required conditions
Synthetic Deterministic Tests / Synthetic offline (deterministic) (push) Waiting to run
Interactive Shell Live (PR + post-merge) / turn-checks (no-LLM) (push) Waiting to run
Interactive Shell Live (PR + post-merge) / turn-live shard ${{ matrix.shard_index }} (push) Waiting to run
CI (OpenClaw E2E) / openclaw test (push) Has been cancelled
171 lines
6.9 KiB
Plaintext
171 lines
6.9 KiB
Plaintext
---
|
||
title: 'eBPF and security'
|
||
sidebarTitle: 'eBPF and security'
|
||
description: 'How Tracer observes execution safely and securely'
|
||
---
|
||
|
||
Tracer uses eBPF (extended Berkeley Packet Filter) to observe execution behavior directly from the Linux kernel. This approach enables high-fidelity visibility with minimal overhead, while maintaining strong safety and security guarantees.
|
||
|
||
This page explains why eBPF is used, what Tracer observes, what it does not observe, and how security is enforced.
|
||
|
||
## Why Tracer uses eBPF
|
||
|
||
Traditional observability approaches depend on logs, metrics exporters, or application-level instrumentation. These methods rely on what software chooses to expose and often miss behavior in short-lived processes, external binaries, or between metric collection intervals.
|
||
|
||
eBPF allows Tracer to observe execution where it actually happens, at the boundary between user processes and the operating system.
|
||
|
||
Using eBPF, Tracer can:
|
||
|
||
- Observe syscalls, scheduling events, and I/O activity
|
||
- Track process lifecycles across containers and hosts
|
||
- Capture execution behavior without modifying application code
|
||
- Work across languages, frameworks, and binaries
|
||
|
||
This makes eBPF well suited for scientific and ML workloads that rely on many heterogeneous tools.
|
||
|
||
<Frame>
|
||
<img src="/images/howTracerWorks.webp" alt="How Tracer works: observing execution at the kernel level using eBPF" />
|
||
</Frame>
|
||
|
||
## Safety model
|
||
|
||
eBPF programs are subject to strict safety constraints enforced by the Linux kernel.
|
||
|
||
Tracer's use of eBPF follows these principles:
|
||
|
||
<AccordionGroup>
|
||
<Accordion title="Verified bytecode">
|
||
All eBPF programs are validated by the kernel verifier before execution. Programs that fail verification cannot run.
|
||
</Accordion>
|
||
<Accordion title="Sandboxed execution">
|
||
eBPF programs run in a restricted environment and cannot access arbitrary memory or crash the kernel.
|
||
</Accordion>
|
||
<Accordion title="No kernel modifications">
|
||
Tracer does not load kernel modules or modify kernel code.
|
||
</Accordion>
|
||
<Accordion title="Controlled attachment points">
|
||
Tracer attaches only to well-defined kernel hooks such as system call boundaries and scheduler events.
|
||
</Accordion>
|
||
</AccordionGroup>
|
||
|
||
These guarantees are provided by the kernel itself and apply regardless of how Tracer is configured.
|
||
|
||
## What Tracer observes
|
||
|
||
Tracer observes execution metadata, not application data.
|
||
|
||
<CardGroup cols={3}>
|
||
<Card title="CPU & scheduling" icon="microchip">
|
||
CPU usage and scheduling behavior
|
||
</Card>
|
||
<Card title="Memory" icon="memory">
|
||
Memory usage and peak memory
|
||
</Card>
|
||
<Card title="I/O activity" icon="hard-drive">
|
||
Disk and network I/O activity
|
||
</Card>
|
||
<Card title="Process lifecycle" icon="diagram-project">
|
||
Process start, stop, and parent–child relationships
|
||
</Card>
|
||
<Card title="Container context" icon="cube">
|
||
Container, namespace, and cgroup context
|
||
</Card>
|
||
</CardGroup>
|
||
|
||
This data is used to reconstruct execution timelines and resource usage patterns.
|
||
|
||
## What Tracer does not observe
|
||
|
||
<Warning>
|
||
**Tracer explicitly does not collect:**
|
||
- Application payloads or scientific input/output data
|
||
- File contents or data values
|
||
- Source code or function-level execution traces
|
||
- Environment variables or secrets
|
||
- Application- or domain-level interpretation of what a command does
|
||
</Warning>
|
||
|
||
While Tracer can observe which binaries and commands were executed, it does not inspect the data those commands operate on or infer application semantics.
|
||
|
||
## Data handling and isolation
|
||
|
||
Tracer separates data collection from analysis.
|
||
|
||
- Execution signals are captured locally and processed into structured telemetry
|
||
- Only metadata required for analysis is transmitted
|
||
- Payload data is never inspected or exported
|
||
- Correlation is based on operating system identifiers (PIDs, cgroups, namespaces)
|
||
|
||
This design minimizes data exposure while preserving execution insight.
|
||
|
||
## Performance considerations
|
||
|
||
Tracer's eBPF-based collection is designed to minimize overhead:
|
||
|
||
<CardGroup cols={2}>
|
||
<Card title="Low latency" icon="bolt">
|
||
eBPF probes execute in kernel space with low latency
|
||
</Card>
|
||
<Card title="Efficient filtering" icon="filter">
|
||
Event filtering reduces data volume at the source
|
||
</Card>
|
||
<Card title="Scales well" icon="chart-line">
|
||
Collection overhead remains low even with many short-lived processes
|
||
</Card>
|
||
<Card title="No re-runs" icon="rotate">
|
||
No pipeline re-runs are required to obtain telemetry
|
||
</Card>
|
||
</CardGroup>
|
||
|
||
<Note>Measured overhead depends on workload characteristics but is typically low enough for continuous use in production environments.</Note>
|
||
|
||
## Security boundaries
|
||
|
||
Tracer is intentionally scoped.
|
||
|
||
<Warning>
|
||
**It does not:**
|
||
- Modify application behavior
|
||
- Control execution or scheduling
|
||
- Start, stop, or change resources
|
||
- Replace IAM, RBAC, or cloud security controls
|
||
</Warning>
|
||
|
||
Security ownership remains with the operating system, container runtime, and cloud provider. Tracer observes execution behavior within those boundaries.
|
||
|
||
## When to read this page
|
||
|
||
This page is most relevant if you:
|
||
|
||
- Need to understand how Tracer observes execution safely
|
||
- Operate in regulated or security-sensitive environments
|
||
- Evaluate eBPF-based tooling for production systems
|
||
- Want clarity on what data Tracer does and does not collect
|
||
|
||
<CardGroup cols={3}>
|
||
<Card href="/technology/tracer-collect">
|
||
<span style={{ fontSize: '1.25rem', fontWeight: '500' }}>
|
||
<span style={{ background: 'linear-gradient(135deg, #FCFCFC, #C4C4C4)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>Tracer/</span><span style={{ background: 'linear-gradient(135deg, #FB68E1, #953E96)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>collect</span>
|
||
</span>
|
||
<br />
|
||
Implementation details
|
||
</Card>
|
||
<Card href="/technology/tracer-tune">
|
||
<span style={{ fontSize: '1.25rem', fontWeight: '500' }}>
|
||
<span style={{ background: 'linear-gradient(135deg, #FCFCFC, #C4C4C4)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>Tracer/</span><span style={{ background: 'linear-gradient(135deg, #38BDA4, #76E9D3)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>tune</span>
|
||
</span>
|
||
<br />
|
||
Execution analysis and optimization
|
||
</Card>
|
||
<Card href="/technology/tracer-sweep">
|
||
<span style={{ fontSize: '1.25rem', fontWeight: '500' }}>
|
||
<span style={{ background: 'linear-gradient(135deg, #FCFCFC, #C4C4C4)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>Tracer/</span><span style={{ background: 'linear-gradient(135deg, #4436BD, #5646E2)', WebkitBackgroundClip: 'text', WebkitTextFillColor: 'transparent', backgroundClip: 'text' }}>sweep</span>
|
||
</span>
|
||
<br />
|
||
Cloud waste discovery
|
||
</Card>
|
||
</CardGroup>
|
||
|
||
<div style={{ height: '50vh' }}></div>
|
||
|