[GH-ISSUE #6013] [Design] Upstream issue #3674

New issue

Open

opened 2026-10-31 00:42:57 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:42:57 +00:00

Owner

Originally created by @Bernardo-Hazan on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6013

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Upstream issue — "Linux arm64 host gates on EVM, pwntools, Wakaru and PSP are verification markers, not dependencies"

Summary. On Linux aarch64 (Ubuntu 24.04, Node 24.22, REA 6.7.0) five capabilities are refused by a
process.arch === "x64" check although every dependency runs natively on arm64:

Tool / profile	Gate	What actually runs
`inspect_evm_interface`	`src/server/createServer.ts:209,224`; `src/evm/EvmoleInterfaceProvider.ts:114,413`	evmole 0.9.3 is pure WASM; prlimit is the system binary. Ran on aarch64 under REA's exact prlimit + Node flags: exit 0, selectors decoded.
`inspect_binary_layout`, `inspect_recorded_crash`	`createServer.ts:209-211`; `src/native/pwntools/PwntoolsDecoder.ts:253`	pwntools 4.15.0 (universal wheel), pyelftools 0.33, unicorn 2.1.2 (cp312 aarch64 wheels). Limits are arch-free constants in the bridges. Recorded crashes already accept AArch64 cores.
`recover_javascript_sources`	`createServer.ts:238-239`; `src/javascript/recovery/WakaruCommand.ts:68`	Upstream Wakaru ships `wakaru-linux-arm64.tar.gz` for v1.5.0 … v1.14.0 (`docs/javascript-recovery.md` says x64-only, which is out of date).
Ghidra PSP (Allegrex)	`src/ghidra/GhidraProvider.ts:252`; `src/ghidra/GhidraPspExtension.ts:210`	ghidra-allegrex is Java/Sleigh; Ghidra itself is already admitted on Linux arm64 (CHANGELOG 12.x).

The rationale in docs/roadmap.md:27-28 is "verified lane" coverage: all real-* workflows run on x64
runners. There is precedent for lifting the gate once a lane exists (Ghidra Linux arm64) and for not
gating at all (WABT, verified only on macOS arm64).

Proposal. Either (a) add an ubuntu-24.04-arm runner to the four real-* lanes and drop the arch
checks, or (b) keep the policy but expose an explicit opt-in (e.g. REA_ALLOW_UNVERIFIED_HOST=1) so
arm64 operators can run these tools while the result profile records "host unverified". We run (b) as a
local 7-line overlay (local/patches/0001-arm64-host-gates.patch in our deployment repo) and would be
glad to contribute it.

Context and evidence

Evidence from our arm64 run (2026-10-21, overlay active): inspect_evm_interface on a 50-byte
dispatcher → selectors 0x70a08231 and 0xa9059cbb with correct offsets; inspect_recorded_crash on an
aarch64 core → thread registers, signals, segments and notes decoded; inspect_binary_layout on an x86-64
ELF → sections/segments/symbols/relocations/mitigations (arm64 ELF still refused by the target check, as
documented); recover_javascript_sources with Wakaru 1.14.0 linux-arm64 on a minified ESM bundle → status
complete; Ghidra 12.1.4 loads the Allegrex extension on arm64. tsc, formatting and the three pinning tests
stay green with the flag unset.

Environment. Linux 7.0.0 aarch64, Ubuntu 24.04, Node 24.22.0, REA 6.7.0 in a container (ubuntu:24.04).

Expected interaction with targets

Not sure yet

Boundary details (optional)

No response

Options and tradeoffs

No response

Verification available so far

Idea only; I need help defining checks

Success criteria and open questions

No response

References

No response

Originally created by @Bernardo-Hazan on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6013 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed # Upstream issue — "Linux arm64 host gates on EVM, pwntools, Wakaru and PSP are verification markers, not dependencies" **Summary.** On Linux aarch64 (Ubuntu 24.04, Node 24.22, REA 6.7.0) five capabilities are refused by a `process.arch === "x64"` check although every dependency runs natively on arm64: | Tool / profile | Gate | What actually runs | | --- | --- | --- | | `inspect_evm_interface` | `src/server/createServer.ts:209,224`; `src/evm/EvmoleInterfaceProvider.ts:114,413` | evmole 0.9.3 is pure WASM; prlimit is the system binary. Ran on aarch64 under REA's exact prlimit + Node flags: exit 0, selectors decoded. | | `inspect_binary_layout`, `inspect_recorded_crash` | `createServer.ts:209-211`; `src/native/pwntools/PwntoolsDecoder.ts:253` | pwntools 4.15.0 (universal wheel), pyelftools 0.33, unicorn 2.1.2 (cp312 aarch64 wheels). Limits are arch-free constants in the bridges. Recorded crashes already accept AArch64 cores. | | `recover_javascript_sources` | `createServer.ts:238-239`; `src/javascript/recovery/WakaruCommand.ts:68` | Upstream Wakaru ships `wakaru-linux-arm64.tar.gz` for v1.5.0 … v1.14.0 (`docs/javascript-recovery.md` says x64-only, which is out of date). | | Ghidra PSP (Allegrex) | `src/ghidra/GhidraProvider.ts:252`; `src/ghidra/GhidraPspExtension.ts:210` | ghidra-allegrex is Java/Sleigh; Ghidra itself is already admitted on Linux arm64 (CHANGELOG 12.x). | The rationale in `docs/roadmap.md:27-28` is "verified lane" coverage: all `real-*` workflows run on x64 runners. There is precedent for lifting the gate once a lane exists (Ghidra Linux arm64) and for not gating at all (WABT, verified only on macOS arm64). **Proposal.** Either (a) add an `ubuntu-24.04-arm` runner to the four real-* lanes and drop the arch checks, or (b) keep the policy but expose an explicit opt-in (e.g. `REA_ALLOW_UNVERIFIED_HOST=1`) so arm64 operators can run these tools while the result profile records "host unverified". We run (b) as a local 7-line overlay (`local/patches/0001-arm64-host-gates.patch` in our deployment repo) and would be glad to contribute it. ### Context and evidence **Evidence from our arm64 run (2026-10-21, overlay active):** `inspect_evm_interface` on a 50-byte dispatcher → selectors `0x70a08231` and `0xa9059cbb` with correct offsets; `inspect_recorded_crash` on an aarch64 core → thread registers, signals, segments and notes decoded; `inspect_binary_layout` on an x86-64 ELF → sections/segments/symbols/relocations/mitigations (arm64 ELF still refused by the target check, as documented); `recover_javascript_sources` with Wakaru 1.14.0 linux-arm64 on a minified ESM bundle → status complete; Ghidra 12.1.4 loads the Allegrex extension on arm64. tsc, formatting and the three pinning tests stay green with the flag unset. **Environment.** Linux 7.0.0 aarch64, Ubuntu 24.04, Node 24.22.0, REA 6.7.0 in a container (ubuntu:24.04). ### Expected interaction with targets Not sure yet ### Boundary details (optional) _No response_ ### Options and tradeoffs _No response_ ### Verification available so far Idea only; I need help defining checks ### Success criteria and open questions _No response_ ### References _No response_

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:42:57 +00:00

bsakaguchi referenced this issue

2026-10-31 00:44:52 +00:00

[GH-ISSUE #6469] [Bug] A 65-name PTX register list marks the object malformed and drops kernel declarations #3879

bsakaguchi referenced this issue

2026-11-01 21:10:58 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471