[GH-ISSUE #1131] Ghidra provider rejects linux/arm64 hosts (hard-coded x64 allowlist) — one-line fix proven working #404

New issue

Closed

opened 2026-10-15 18:24:48 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:24:48 +00:00

Owner

Originally created by @TheAndersMadsen on GitHub (Oct 8, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1131

Summary

REA 6.0.0's Ghidra provider hard-codes a host allowlist that rejects linux/arm64, even though the underlying stack works there. Every native command fails with provider_unavailable: unsupported_host on aarch64 Linux hosts.

Upstream docs state Ghidra support as "Linux x64 and macOS x64/arm64" — but the darwin arm64 path in the same check shows arm64 support is policy, not physics: on this host (linux/arm64, Node 26, Temurin 21 arm64, a locally built Decompiler/build/os/linux_arm_64/decompile), admitting linux/arm64 in the same check produces a fully working provider.

Environment

Host: Linux aarch64
Node: v26.10.0
REA: rea-agents 6.0.0 (npm)
JDK: Temurin 21 (arm64), JAVA_HOME set
Ghidra: headless analyzer present, GHIDRA_INSTALL_DIR set (decompiler built for linux_arm_64)

Reproduction

rea doctor --provider ghidra --json on linux/arm64 → unsupported_host (all other checks: java ✓, headless ✓, install ✓, version ✓).
Any native command (analyze, function, decompile, xrefs) → provider_unavailable.

Root cause

dist/ghidra/GhidraInstallation.js (installation check):

architecture === "x64") ||   // linux arm64 never admitted

Proven one-line fix

(architecture === "x64" ||
    (platform === "linux" && architecture === "arm64"))) ||

Post-patch doctor: fully healthy. End-to-end probe on a real 1.19MB PE binary: analyze = 91s cold, 13,418 procedures, sha256-pinned Evidence envelope; function/decompile/xrefs all working; identical repeat queries hit the snapshot cache (1s, same evidence_id). The arm64 JDK + locally built arm64 decompiler + REA's Java bridge run the whole pipeline cleanly — verified over a multi-hour evaluation.

Request

Admit linux && arm64 in the Ghidra installation architecture check (mirroring the existing darwin arm64 path), or gate it on the presence of a built linux_arm_64 decompiler binary rather than the host allowlist.

Happy to test a release build on this host. (Filed by an automated fleet evaluation; local evidence artifacts retained.)

Originally created by @TheAndersMadsen on GitHub (Oct 8, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1131 ## Summary REA 6.0.0's Ghidra provider hard-codes a host allowlist that rejects linux/arm64, even though the underlying stack works there. Every native command fails with `provider_unavailable: unsupported_host` on aarch64 Linux hosts. Upstream docs state Ghidra support as "Linux x64 and macOS x64/arm64" — but the darwin arm64 path in the same check shows arm64 support is policy, not physics: on this host (linux/arm64, Node 26, Temurin 21 arm64, a locally built `Decompiler/build/os/linux_arm_64/decompile`), admitting linux/arm64 in the same check produces a **fully working provider**. ## Environment - Host: Linux aarch64 - Node: v26.10.0 - REA: rea-agents 6.0.0 (npm) - JDK: Temurin 21 (arm64), `JAVA_HOME` set - Ghidra: headless analyzer present, `GHIDRA_INSTALL_DIR` set (decompiler built for linux_arm_64) ## Reproduction 1. `rea doctor --provider ghidra --json` on linux/arm64 → `unsupported_host` (all other checks: java ✓, headless ✓, install ✓, version ✓). 2. Any native command (`analyze`, `function`, `decompile`, `xrefs`) → `provider_unavailable`. ## Root cause `dist/ghidra/GhidraInstallation.js` (installation check): ```js architecture === "x64") || // linux arm64 never admitted ``` ## Proven one-line fix ```js (architecture === "x64" || (platform === "linux" && architecture === "arm64"))) || ``` Post-patch `doctor`: fully healthy. End-to-end probe on a real 1.19MB PE binary: `analyze` = 91s cold, 13,418 procedures, sha256-pinned Evidence envelope; function/decompile/xrefs all working; identical repeat queries hit the snapshot cache (1s, same evidence_id). The arm64 JDK + locally built arm64 decompiler + REA's Java bridge run the whole pipeline cleanly — verified over a multi-hour evaluation. ## Request Admit `linux && arm64` in the Ghidra installation architecture check (mirroring the existing darwin arm64 path), or gate it on the presence of a built `linux_arm_64` decompiler binary rather than the host allowlist. Happy to test a release build on this host. (Filed by an automated fleet evaluation; local evidence artifacts retained.)

bsakaguchi

2026-10-15 18:24:48 +00:00

closed this issue
added the
area: native

bug
labels

bsakaguchi commented

2026-10-15 18:24:48 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 9, 2026):

Verified the fix on a native Linux arm64 runner with Ghidra 12.1.4 and JDK 21. The unchanged host-native verifier passed debug, stripped and type-layout fixtures, real decompilation, CLI/stdio-MCP parity (221 successful / 51 rejected boundary calls), annotation rollback, startup cancellation and complete cleanup.

Real-provider run and downloadable evidence.

This remains conditional on matching native components: the verification built the arm64 decompiler and GNU demangler from the pinned upstream release in an isolated directory. An installation without the arm64 decompiler was also correctly rejected before launch. This does not claim that stock distributions ship those components.

@N0zoM1z0 commented on GitHub (Oct 9, 2026): Verified the fix on a native Linux arm64 runner with Ghidra 12.1.4 and JDK 21. The unchanged host-native verifier passed debug, stripped and type-layout fixtures, real decompilation, CLI/stdio-MCP parity (221 successful / 51 rejected boundary calls), annotation rollback, startup cancellation and complete cleanup. [Real-provider run and downloadable evidence](https://github.com/morluto/rea/actions/runs/37866744136). This remains conditional on matching native components: the verification built the arm64 decompiler and GNU demangler from the pinned upstream release in an isolated directory. An installation without the arm64 decompiler was also correctly rejected before launch. This does not claim that stock distributions ship those components.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:12:57 +00:00

[PR #420] [MERGED] feat(javascript): add bounded semantic tracing #1969

bsakaguchi referenced this issue

2026-10-16 21:13:04 +00:00

[PR #433] [MERGED] feat: add runtime reconstruction roadmap workflows #1982