Multi-Architecture Support

Per-architecture capability matrix for the LinuxGuard agent — ARMv7 Degraded mode, RISC-V best-effort, and the eBPF probe gap operators must plan around.

LinuxGuard ships agent binaries for multiple CPU architectures, but eBPF probe availability is not uniform across architectures. This page is the canonical capability matrix every operator MUST consult before deploying to a non-x86_64 fleet.

Important: On ARMv7 (arm), the agent runs in Degraded mode. The build emits an empty .skip sentinel for eBPF probes — no probes.bpf.o is ever produced for ARMv7, and the loader falls through to DegradedNoEBPFArch. The agent process still runs, but no behavioral telemetry, no auth events, and no eBPF-derived file-monitor events are produced. Compliance assumptions that depend on behavioral telemetry will not be met on ARMv7. Source: verified against the agent source.

Important: RISC-V (riscv64) is best-effort. The build attempts to compile the eBPF probe with clang; on toolchain failure it emits the .skip sentinel and the agent falls through to the same DegradedNoEBPFArch path described above for ARMv7. Whether eBPF probes are available on RISC-V depends entirely on the clang/LLVM toolchain at build time, and is not guaranteed on any given build. Source: verified against the agent source.

Architecture Capability Matrix

The columns below describe the granular surface every per-architecture deployment MUST reason about. A single "Supported" column would conflate the build-time eBPF availability with the runtime feature surface and would not match operator reality.

Arch	Binary	eBPF probes	Behavioral telemetry	Auth events	File monitor	CI-tested
amd64 (x86_64)	Yes	Yes (full clang/LLVM compile)	Yes	Yes	Yes	Yes
arm64 (aarch64)	Yes	Yes (full clang/LLVM compile)	Yes	Yes	Yes	Yes
armv7 (arm)	Yes	No (.skip sentinel; loader falls back to DegradedNoEBPFArch)	No	Limited (no eBPF-derived events)	Limited (no eBPF-derived events)	Best-effort
riscv64	Yes	Best-effort (clang attempt; .skip on toolchain failure)	Conditional (depends on probe success)	Conditional	Conditional	No
s390x	Unverified — do not rely on without confirmation against latest source build	Unverified	Unverified	Unverified	Unverified	No
ppc64le	Unverified — do not rely on without confirmation against latest source build	Unverified	Unverified	Unverified	Unverified	No

Reading the Matrix

• Binary — Whether the agent binary is produced for the architecture in the published build pipeline.

• eBPF probes — Whether probes.bpf.o is compiled and shipped. ARMv7 always emits an empty .skip sentinel; RISC-V emits the same sentinel only when the clang toolchain fails. The loader treats a zero-byte probes.bpf.o as the sentinel and short-circuits to DegradedNoEBPFArch.

• Behavioral telemetry — eBPF-derived process exec, network, and syscall events. Requires functioning eBPF probes.

• Auth events — eBPF-derived login and SSH session events (loginUID capture). Requires functioning eBPF probes.

• File monitor — eBPF-derived file open/exec/write monitoring. Requires functioning eBPF probes.

• CI-tested — Whether the architecture runs in the LinuxGuard CI matrix on every build.

For s390x and ppc64le: the agent binary may build via the OCI multi-arch manifest, but the eBPF probe build path is not exercised in the per-architecture build loop. Verify against the latest packaged build before relying on either architecture in production.

Per-Distribution Architecture Support

Each distribution family ships agent packages for the architectures listed below. Distribution order is fixed across this documentation set: Debian/Ubuntu → RedHat/CentOS → SUSE → Alpine.

Distribution Family	amd64	arm64	armv7	riscv64	Package repo
Debian / Ubuntu	Yes	Yes	Yes (Degraded mode)	No	packages.linuxguard.io/apt
RedHat / CentOS	Yes	Yes	No	No	packages.linuxguard.io/dnf
SUSE / openSUSE	Yes	Yes	No	No	packages.linuxguard.io/zypper
Alpine	Yes	Yes	Yes (Degraded mode)	Best-effort	packages.linuxguard.io/apk

ARMv7 packages on Debian/Ubuntu and Alpine install the agent binary, but the resulting deployment runs in Degraded mode per the matrix above. Each per-distribution install guide cross-links here.

How the Agent Detects Architecture and Falls Back

At startup, the agent resolves the eBPF object path and stats the file. The container image build writes an empty probes.bpf.o on architectures without eBPF support. When the agent observes a regular file with size 0, it:

1. Sets the agent status to AgentStatusDegradedNoEBPFArch.

2. Logs eBPF object is empty sentinel — arch does not support eBPF (DegradedNoEBPFArch) at INFO level.

3. Skips the eBPF loader entirely — no probe attach, no eBPF goroutines, no eBPF telemetry.

4. Continues running with the non-eBPF feature subset (configuration management, package inventory, syslog forwarding, support-bundle collection).

This means linuxguard-agent will start and stay running on ARMv7. The Degraded mode does not crash; it silently drops the eBPF-derived telemetry surface. Operators MUST verify the agent status via the console or linuxguard-agent status after deploying to an ARMv7 host.

Operational Notes

Identifying the Architecture at Runtime

Use uname -m on the host to confirm the architecture before consulting the matrix above:

uname -m

Common mappings:

uname -m output	Matrix row
x86_64	amd64
aarch64	arm64
armv7l / armv6l / arm	armv7
riscv64	riscv64
s390x	s390x
ppc64le	ppc64le

QEMU vs Native Builds

Multi-architecture OCI images produced via QEMU may pass the build but exhibit different runtime characteristics on native hardware (kernel version differences, BPF helper availability). Always test the agent on the target hardware before relying on the published image for production.

Compliance Implications

If your compliance posture depends on continuous behavioral telemetry (e.g., process exec audit, SSH session capture, file integrity monitoring), ARMv7 deployments will NOT contribute that evidence. Treat ARMv7 hosts as a documented gap in your evidence chain, or restrict the deployment to architectures with full eBPF support (amd64, arm64).

Cross-References

• Supported Distributions — Canonical per-architecture and per-distribution matrix.

• Installation on Debian / Ubuntu — Per-distribution install guide (includes ARMv7 cross-link).

• Installation on RedHat / CentOS — Per-distribution install guide.

• Installation on SUSE / openSUSE — Per-distribution install guide.

• Installation on Alpine Linux — Per-distribution install guide.

• Prerequisites — Kernel and system requirements.

---

Related: Supported Distributions | Installation Overview | Troubleshooting