morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8190] [Design] Investigate partial outgoing data-reference evidence for Kuna functions #6474

New issue

Open

opened 2026-11-01 21:11:25 +00:00 by bsakaguchi · 12 comments

bsakaguchi commented

2026-11-01 21:11:25 +00:00

Owner

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

Before submitting

I searched 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

Can REA help an analyst inspect a function's outgoing data references with Kuna, while preserving the semantics and incomplete coverage of the underlying evidence? How should such observations relate to the existing procedure_references and function dossier contracts?

Context and evidence

On a self-built, unexecuted arm64 Mach-O (SHA-256 ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d), source function _adjust reads the global global_count at 0x100004000.

In real REA MCP with Ghidra 12.1.4, procedure_references({"procedure":"_adjust","direction":"outgoing"}) reported a READ from 0x100000420 to 0x100004000, along with stack references.
In REA MCP with Kuna 1.986, procedure_references returned capability_unavailable, and the function dossier explicitly limited its outgoing graph to call-kind edges. procedure_callees did return the known _evaluate to _adjust call.
Direct kuna xrefs <binary> --from _adjust --json returned a data edge from 0x10000041c to 0x100004000 for the address-forming adrp instruction, not a read edge for the later load. --kind read,write returned no edges. The same result labeled global_count as a to_function, consistent with the separately reported inventory misclassification in #8168.
Direct kuna xrefs --from _evaluate returned the expected call and also a data edge whose source and target were the call instruction's own address. Its meaning and validity remain unknown. This is one fixture, not a general accuracy or coverage estimate.

This matters for questions such as “which globals are referenced by this function?” Existing REA references, call graphs and data-flow models carry different meaning; the upstream output is not evidence that the currently advertised Ghidra-style reference contract can simply be reused unchanged.

Expected interaction with targets

Read existing files or captured data and launch the existing caller-supplied static provider. Do not execute the target.

Boundary details (optional)

Preserve source and target coordinates, address-space and image mapping, edge kinds, instruction evidence, provider identity and profile, incomplete/unknown coverage, and disagreement between evidence sources. Do not infer that an address-forming instruction performs a read or that an upstream to_function is a verified function. Treat unresolved or filtered-out observations as unknown, not absence.

Options and tradeoffs

Investigate a bounded provider-neutral observation or explicitly partial extension to an existing analyst workflow. Compare Kuna's --from semantics with Ghidra ReferenceManager and other providers before deciding whether to expose these under a shared contract. A raw CLI wrapper would not resolve the coverage and classification differences.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise independent call, branch, address-formation, data load/store, literal, indirect, alias and unmapped cases; compare positive and negative examples across architectures. Verify CLI/MCP Evidence and empty-result semantics. Establish what the apparent self-reference represents before filtering it or treating it as a valid data edge.

References

Related: #8168 (Kuna inventory includes data), #8170 (Kuna original byte reads), #8184 (feature-trace reference coverage). REA source baseline d48e472fa plus unrelated Kuna version baseline changes in #8187; macOS arm64.

Kuna v1.988 release control

On main 53363166f, macOS arm64 and real compact stdio MCP, the same owned, unexecuted AArch64 call-site and PC-relative fixtures were analyzed with released Kuna 1.986 and 1.988 in isolated caches. In 1.986, xrefs returned each of four BL call sites as its own incoming reference; 1.988 returned none of those four. Both versions retained the tested real call-target incoming reference, four callee addresses, the reached call path and the legitimate address-formation self-reference. For the adjacent-instruction ADR control, 1.986 returned no reference and 1.988 returned the expected earlier instruction; both kept the tested later reference. Fixture digests were unchanged. This corroborates the release on two fixtures, not every data-reference kind, architecture or source-coverage claim.

REA recorded the 1.988 binary and version with verified_release: false, because its release policy still names 1.986. The complete real verify:kuna lane also passed with 1.988 on this host for generated Mach-O and supplied symbol-bearing/stripped ELF fixtures, reporting verified process lineage and complete cleanup. That alone does not establish cross-platform verification or mean this broader outgoing-reference design question is resolved.

Kuna 1.988 read, write and address controls

On REA 859e5fb95 (based on d3ab0faf5 with an unrelated function-matching change), macOS arm64, real compact stdio MCP and direct Kuna 1.988 re-examined the original unexecuted workflow Mach-O (SHA-256 ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d, unchanged). Unlike the 1.986 result above, direct kuna xrefs --from _adjust --json now reports both the data ADRP at 0x10000041c and a read LDR at 0x100000420 to 0x100004000; to_function is null. REA/Kuna still reports procedure_references as capability_unavailable, while its procedure assembly shows the load and address. Real REA/Ghidra returns outgoing reference Evidence for the same function. This is a changed upstream observation, not a new claim of complete reference coverage.

A second source-owned, unexecuted arm64 Mach-O independently separates audit_read, audit_write and audit_address functions against the same volatile global at 0x100004000. Direct Kuna 1.988 reports, respectively: data at 0x1000003c0 and read at 0x1000003c4; data at 0x1000003d8 and write at 0x1000003dc; and data at 0x1000003e8. otool -tvV confirms ADRP/LDR, ADRP/STR and ADRP/ADD respectively. Real REA/Ghidra reports the global READ at 0x1000003c4, WRITE at 0x1000003dc, and DATA at 0x1000003ec (the ADD, rather than Kuna's ADRP). REA/Kuna returns capability_unavailable for all three procedure_references requests. The second fixture SHA-256 was unchanged (b5df909ecf873463f83af441d75127d92da78dfe759749a7221216f6ec671171).

These controls show a useful 1.988 capability that the current REA route cannot convey, and demonstrate provider-specific differences in where address formation is attributed. They do not establish equivalence of provider kinds, exhaustive reference coverage, behavior on other architectures or profiles, or runtime memory access. A shared design must preserve each provider's observation and unknown classification fields rather than inventing Ghidra-style false flags.

x86-64 read, write, address and unknown-target control

On REA branch ae8223ccdfa0d5dbc659ddcbb7d6acf360343c3f, macOS arm64, direct Kuna 1.988 and real Ghidra 12.1.4 stdio MCP, a source-owned x86-64 ELF contains separate mov global(%rip), %eax, mov %edi, global(%rip), lea global(%rip), %rax, mov (%rdi), %eax, and immediate-only functions. Independent LLVM disassembly confirms these instructions. Kuna xrefs --from returned respectively read, write, and data at source offsets 0x1248, 0x124f, and 0x1256, all targeting 0x32d8; both the indirect-load and immediate-only functions returned no outgoing rows. REA/Kuna procedure_references returned capability_unavailable for all five while procedure_assembly showed the instructions.

REA/Ghidra procedure_references returned corresponding READ, WRITE, and DATA observations in its separately mapped coordinates (0x101248, 0x10124f, 0x101256 → 0x1032d8). It returned empty recorded reference lists for both the indirect load and immediate-only function. Its generic Evidence limitation identifies Ghidra ReferenceManager as the source, but neither empty list alone distinguishes a memory access with an unknown target from no memory instruction. In a separate compact MCP control, analyze_function reported a high-p-code memory_read effect for the indirect load, while the direct read and write had empty effects and appeared in the reference results instead (see #8336). These observations do not prove runtime accesses or exhaustive inventories.

Both providers were exercised in full and compact MCP profiles for references and assembly; successful replies validated against advertised output schemas. The dossier control was compact only. The target was not executed and its SHA-256 remained d3baa5cf385b68e3a8de02ed0884d9c9e781bd2c6b63201250635e4dc37655e8. An initial combined harness timed out before logging the stalled request; separately instrumented provider/profile runs completed. These are constructed fixtures on one host, not coverage or frequency estimates.

Released Kuna 1.989 and indirect-read control

On main 9ebbe67e, macOS arm64, I built a new owned, unexecuted arm64 Mach-O with separate volatile-global read, write, address-return and pointer-parameter indirect-read functions. Direct released Kuna 1.989 xrefs --from reported data at 0x1000003c0 and read at 0x1000003c4 for the global read; data at 0x1000003d8 and write at 0x1000003dc for the global write; and data at 0x1000003e8 for the global address. All target 0x100004000. Its indirect-read query had no outgoing rows, while its coverage reported the function decoded; that does not establish absence of an indirect read. otool -tvV independently showed the global ADRP/LDR and ADRP/STR, ADRP/ADD address formation, and the pointer-parameter LDR at 0x100000400.

In real compact and full stdio MCP, REA/Kuna returned capability_unavailable for outgoing procedure_references on all four, while procedure_assembly succeeded. REA/Ghidra 12.1.4 reported the global READ at 0x1000003c4, WRITE at 0x1000003dc, and DATA at 0x1000003ec; the write and indirect functions also had stack references. The indirect target did not appear as a resolved outgoing reference. In a separate compact-profile complete Ghidra dossier, native_value_flow.effects reported a memory_read at 0x100000400#6, an existing workflow that preserves the indirect access without inventing a destination.

The fixture SHA-256 64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7 remained unchanged. Successful calls used fetched SDK definitions. This confirms behavior on one constructed fixture and host, not provider completeness, runtime access, or automatic agent selection. Kuna's --from row address_hex is the destination in this result; the source sites above use from_address_hex.

Existing value-trace alternative for the indirect load

On the same arm64 fixture and main 9ebbe67e, real trace_native_values({procedure: "_audit_indirect"}) in both compact and full MCP profiles returned, with Ghidra 12.1.4, a four-node/three-edge trace: parameter ordinal 0 has a derived parameter-use edge to the LOAD at 0x100000400#6, followed by def-use edges through a copy to the return. The trace's limitations state alias dependencies remain unknown; it does not name a concrete memory destination or prove runtime behavior. The node's reported is_dead: true and block_membership: member remain distinct as documented.

With released Kuna 1.989, the same public workflow returned an explicit Provider has no native def-use model unknown and zero nodes rather than a resolved trace, in both profiles. This is an existing Ghidra route for the pointer-use question, not a substitute for the missing Kuna outgoing-reference support. The target SHA-256 64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7 was unchanged and it was not run.

Value-trace handoff qualification

On main 9ebbe67e, repeating the Ghidra value trace for this same _audit_indirect fixture and exporting Evidence reproduced #8282 in compact and full MCP profiles: the trace and alias limitation were retained, but the repeated trace's procedure source ID was absent after import into a fresh server. Its top-level Evidence link cited the retained original source instead. Separate #8384 head a20c186eb81785c96267f33cec3929ea5aeb8130 retained and resolved the source in the same real-provider offline control. A disposable merge of #8384 and #8734 also passed the tested trace and pseudocode replay handoffs; see #8282 for exact scope. These checks do not change the observed load graph or establish a concrete indirect destination. The unexecuted fixture SHA-256 64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7 remained unchanged.

Instruction-local Kuna p-code control

Direct Kuna 1.989 raw-pcode <fixture> 0x100000400 --count 1 --json on the indirect-read fixture returned one ldr w0, [x8] instruction with a LOAD operation and instruction bytes 000140b9. This confirms Kuna exposes an instruction-local memory operation even when its outgoing xref query returned no resolved destination. It does not independently connect the loaded address to the function parameter: the Ghidra high-p-code trace above supplies a different, decompiler-derived def-use observation. REA/Kuna does not expose this direct command as trace_native_values; the existing tool returns an unavailable-def-use unknown. A future design should distinguish raw instruction semantics from high-p-code def-use, keep unresolved memory targets unknown, and choose the analyst task before considering a provider-specific surface. The unexecuted fixture SHA-256 remained 64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7.

Raw p-code scope controls

On the same unexecuted fixture with Kuna 1.989, separate one-instruction raw-p-code queries reported COPY for the global address-forming adrp at 0x1000003c0; COPY, LOAD, INT_ZEXT for the global ldr at 0x1000003c4; COPY, STORE for the global str at 0x1000003dc; and COPY, RETURN for the return at 0x100000408. The indirect ldr at 0x100000400 had the same instruction bytes (000140b9) and identical instruction-local p-code operations as the global load at 0x1000003c4. Its address register has a different preceding origin, not visible from that single-instruction observation. Each response reported stop_reason: instruction_limit, so no function-level coverage is implied. Target SHA-256 remained 64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7.

This concrete contrast supports exposing memory-op observations with their scope and provenance if they answer an analyst's question, while requiring separate data-flow or xref evidence for a target. It does not justify treating every LOAD as a global read, inventing a resolved object, or presenting instruction-local p-code as high-p-code def-use.

Existing Ghidra instruction observation

On the same fixture, real Ghidra 12.1.4 CLI inspect-native-instruction at 0x100000400 returned status: decoded, bytes 000140b9, mnemonic ldr, and operand tokens w0 and [x8]; its references were empty and memory_addressing was unavailable. The earlier Ghidra dossier and value trace separately identified a decompiler-derived memory-read effect and parameter use. Thus the existing instruction tool can expose the actual decoded instruction without inventing a destination, but this result does not itself provide a typed memory-read effect or the parameter-to-load data flow. Kuna's raw p-code control above is likewise instruction-local, though it explicitly includes a LOAD operation. The target SHA-256 remained 64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7. No comparative latency, memory, token or completeness measurement was performed.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8190 ### Before submitting - [x] I searched open and closed issues and pull requests for a related discussion. - [x] I understand the 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 Can REA help an analyst inspect a function's outgoing data references with Kuna, while preserving the semantics and incomplete coverage of the underlying evidence? How should such observations relate to the existing `procedure_references` and function dossier contracts? ### Context and evidence On a self-built, unexecuted arm64 Mach-O (SHA-256 `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`), source function `_adjust` reads the global `global_count` at `0x100004000`. - In real REA MCP with Ghidra 12.1.4, `procedure_references({"procedure":"_adjust","direction":"outgoing"})` reported a `READ` from `0x100000420` to `0x100004000`, along with stack references. - In REA MCP with Kuna 1.986, `procedure_references` returned `capability_unavailable`, and the function dossier explicitly limited its outgoing graph to call-kind edges. `procedure_callees` did return the known `_evaluate` to `_adjust` call. - Direct `kuna xrefs <binary> --from _adjust --json` returned a `data` edge from `0x10000041c` to `0x100004000` for the address-forming `adrp` instruction, not a `read` edge for the later load. `--kind read,write` returned no edges. The same result labeled `global_count` as a `to_function`, consistent with the separately reported inventory misclassification in #8168. - Direct `kuna xrefs --from _evaluate` returned the expected call and also a `data` edge whose source and target were the call instruction's own address. Its meaning and validity remain unknown. This is one fixture, not a general accuracy or coverage estimate. This matters for questions such as “which globals are referenced by this function?” Existing REA references, call graphs and data-flow models carry different meaning; the upstream output is not evidence that the currently advertised Ghidra-style reference contract can simply be reused unchanged. ### Expected interaction with targets Read existing files or captured data and launch the existing caller-supplied static provider. Do not execute the target. ### Boundary details (optional) Preserve source and target coordinates, address-space and image mapping, edge kinds, instruction evidence, provider identity and profile, incomplete/unknown coverage, and disagreement between evidence sources. Do not infer that an address-forming instruction performs a read or that an upstream `to_function` is a verified function. Treat unresolved or filtered-out observations as unknown, not absence. ### Options and tradeoffs Investigate a bounded provider-neutral observation or explicitly partial extension to an existing analyst workflow. Compare Kuna's `--from` semantics with Ghidra ReferenceManager and other providers before deciding whether to expose these under a shared contract. A raw CLI wrapper would not resolve the coverage and classification differences. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise independent call, branch, address-formation, data load/store, literal, indirect, alias and unmapped cases; compare positive and negative examples across architectures. Verify CLI/MCP Evidence and empty-result semantics. Establish what the apparent self-reference represents before filtering it or treating it as a valid data edge. ### References Related: #8168 (Kuna inventory includes data), #8170 (Kuna original byte reads), #8184 (feature-trace reference coverage). REA source baseline `d48e472fa` plus unrelated Kuna version baseline changes in #8187; macOS arm64. ### Kuna v1.988 release control On main `53363166f`, macOS arm64 and real compact stdio MCP, the same owned, unexecuted AArch64 call-site and PC-relative fixtures were analyzed with released Kuna 1.986 and 1.988 in isolated caches. In 1.986, `xrefs` returned each of four BL call sites as its own incoming reference; 1.988 returned none of those four. Both versions retained the tested real call-target incoming reference, four callee addresses, the reached call path and the legitimate address-formation self-reference. For the adjacent-instruction ADR control, 1.986 returned no reference and 1.988 returned the expected earlier instruction; both kept the tested later reference. Fixture digests were unchanged. This corroborates the release on two fixtures, not every data-reference kind, architecture or source-coverage claim. REA recorded the 1.988 binary and version with `verified_release: false`, because its release policy still names 1.986. The complete real `verify:kuna` lane also passed with 1.988 on this host for generated Mach-O and supplied symbol-bearing/stripped ELF fixtures, reporting verified process lineage and complete cleanup. That alone does not establish cross-platform verification or mean this broader outgoing-reference design question is resolved. ### Kuna 1.988 read, write and address controls On REA `859e5fb95` (based on `d3ab0faf5` with an unrelated function-matching change), macOS arm64, real compact stdio MCP and direct Kuna 1.988 re-examined the original unexecuted `workflow` Mach-O (SHA-256 `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`, unchanged). Unlike the 1.986 result above, direct `kuna xrefs --from _adjust --json` now reports both the `data` ADRP at `0x10000041c` and a `read` LDR at `0x100000420` to `0x100004000`; `to_function` is null. REA/Kuna still reports `procedure_references` as `capability_unavailable`, while its procedure assembly shows the load and address. Real REA/Ghidra returns outgoing reference Evidence for the same function. This is a changed upstream observation, not a new claim of complete reference coverage. A second source-owned, unexecuted arm64 Mach-O independently separates `audit_read`, `audit_write` and `audit_address` functions against the same volatile global at `0x100004000`. Direct Kuna 1.988 reports, respectively: `data` at `0x1000003c0` and `read` at `0x1000003c4`; `data` at `0x1000003d8` and `write` at `0x1000003dc`; and `data` at `0x1000003e8`. `otool -tvV` confirms ADRP/LDR, ADRP/STR and ADRP/ADD respectively. Real REA/Ghidra reports the global READ at `0x1000003c4`, WRITE at `0x1000003dc`, and DATA at `0x1000003ec` (the ADD, rather than Kuna's ADRP). REA/Kuna returns `capability_unavailable` for all three `procedure_references` requests. The second fixture SHA-256 was unchanged (`b5df909ecf873463f83af441d75127d92da78dfe759749a7221216f6ec671171`). These controls show a useful 1.988 capability that the current REA route cannot convey, and demonstrate provider-specific differences in where address formation is attributed. They do not establish equivalence of provider kinds, exhaustive reference coverage, behavior on other architectures or profiles, or runtime memory access. A shared design must preserve each provider's observation and unknown classification fields rather than inventing Ghidra-style false flags. ### x86-64 read, write, address and unknown-target control On REA branch `ae8223ccdfa0d5dbc659ddcbb7d6acf360343c3f`, macOS arm64, direct Kuna 1.988 and real Ghidra 12.1.4 stdio MCP, a source-owned x86-64 ELF contains separate `mov global(%rip), %eax`, `mov %edi, global(%rip)`, `lea global(%rip), %rax`, `mov (%rdi), %eax`, and immediate-only functions. Independent LLVM disassembly confirms these instructions. Kuna `xrefs --from` returned respectively `read`, `write`, and `data` at source offsets `0x1248`, `0x124f`, and `0x1256`, all targeting `0x32d8`; both the indirect-load and immediate-only functions returned no outgoing rows. REA/Kuna `procedure_references` returned `capability_unavailable` for all five while `procedure_assembly` showed the instructions. REA/Ghidra `procedure_references` returned corresponding `READ`, `WRITE`, and `DATA` observations in its separately mapped coordinates (`0x101248`, `0x10124f`, `0x101256` → `0x1032d8`). It returned empty recorded reference lists for both the indirect load and immediate-only function. Its generic Evidence limitation identifies Ghidra ReferenceManager as the source, but neither empty list alone distinguishes a memory access with an unknown target from no memory instruction. In a separate compact MCP control, `analyze_function` reported a high-p-code `memory_read` effect for the indirect load, while the direct read and write had empty effects and appeared in the reference results instead (see #8336). These observations do not prove runtime accesses or exhaustive inventories. Both providers were exercised in full and compact MCP profiles for references and assembly; successful replies validated against advertised output schemas. The dossier control was compact only. The target was not executed and its SHA-256 remained `d3baa5cf385b68e3a8de02ed0884d9c9e781bd2c6b63201250635e4dc37655e8`. An initial combined harness timed out before logging the stalled request; separately instrumented provider/profile runs completed. These are constructed fixtures on one host, not coverage or frequency estimates. ### Released Kuna 1.989 and indirect-read control On main `9ebbe67e`, macOS arm64, I built a new owned, unexecuted arm64 Mach-O with separate volatile-global read, write, address-return and pointer-parameter indirect-read functions. Direct released Kuna 1.989 `xrefs --from` reported `data` at `0x1000003c0` and `read` at `0x1000003c4` for the global read; `data` at `0x1000003d8` and `write` at `0x1000003dc` for the global write; and `data` at `0x1000003e8` for the global address. All target `0x100004000`. Its indirect-read query had no outgoing rows, while its coverage reported the function decoded; that does not establish absence of an indirect read. `otool -tvV` independently showed the global ADRP/LDR and ADRP/STR, ADRP/ADD address formation, and the pointer-parameter LDR at `0x100000400`. In real compact and full stdio MCP, REA/Kuna returned `capability_unavailable` for outgoing `procedure_references` on all four, while `procedure_assembly` succeeded. REA/Ghidra 12.1.4 reported the global READ at `0x1000003c4`, WRITE at `0x1000003dc`, and DATA at `0x1000003ec`; the write and indirect functions also had stack references. The indirect target did not appear as a resolved outgoing reference. In a separate compact-profile complete Ghidra dossier, `native_value_flow.effects` reported a `memory_read` at `0x100000400#6`, an existing workflow that preserves the indirect access without inventing a destination. The fixture SHA-256 `64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7` remained unchanged. Successful calls used fetched SDK definitions. This confirms behavior on one constructed fixture and host, not provider completeness, runtime access, or automatic agent selection. Kuna's `--from` row `address_hex` is the destination in this result; the source sites above use `from_address_hex`. ### Existing value-trace alternative for the indirect load On the same arm64 fixture and main `9ebbe67e`, real `trace_native_values({procedure: "_audit_indirect"})` in both compact and full MCP profiles returned, with Ghidra 12.1.4, a four-node/three-edge trace: parameter ordinal 0 has a derived `parameter-use` edge to the `LOAD` at `0x100000400#6`, followed by def-use edges through a copy to the return. The trace's limitations state alias dependencies remain unknown; it does not name a concrete memory destination or prove runtime behavior. The node's reported `is_dead: true` and `block_membership: member` remain distinct as documented. With released Kuna 1.989, the same public workflow returned an explicit `Provider has no native def-use model` unknown and zero nodes rather than a resolved trace, in both profiles. This is an existing Ghidra route for the pointer-use question, not a substitute for the missing Kuna outgoing-reference support. The target SHA-256 `64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7` was unchanged and it was not run. ### Value-trace handoff qualification On main `9ebbe67e`, repeating the Ghidra value trace for this same `_audit_indirect` fixture and exporting Evidence reproduced #8282 in compact and full MCP profiles: the trace and alias limitation were retained, but the repeated trace's procedure source ID was absent after import into a fresh server. Its top-level Evidence link cited the retained original source instead. Separate #8384 head `a20c186eb81785c96267f33cec3929ea5aeb8130` retained and resolved the source in the same real-provider offline control. A disposable merge of #8384 and #8734 also passed the tested trace and pseudocode replay handoffs; see #8282 for exact scope. These checks do not change the observed load graph or establish a concrete indirect destination. The unexecuted fixture SHA-256 `64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7` remained unchanged. ### Instruction-local Kuna p-code control Direct Kuna 1.989 `raw-pcode <fixture> 0x100000400 --count 1 --json` on the indirect-read fixture returned one `ldr w0, [x8]` instruction with a `LOAD` operation and instruction bytes `000140b9`. This confirms Kuna exposes an instruction-local memory operation even when its outgoing xref query returned no resolved destination. It does not independently connect the loaded address to the function parameter: the Ghidra high-p-code trace above supplies a different, decompiler-derived def-use observation. REA/Kuna does not expose this direct command as `trace_native_values`; the existing tool returns an unavailable-def-use unknown. A future design should distinguish raw instruction semantics from high-p-code def-use, keep unresolved memory targets unknown, and choose the analyst task before considering a provider-specific surface. The unexecuted fixture SHA-256 remained `64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7`. ### Raw p-code scope controls On the same unexecuted fixture with Kuna 1.989, separate one-instruction raw-p-code queries reported `COPY` for the global address-forming `adrp` at `0x1000003c0`; `COPY, LOAD, INT_ZEXT` for the global `ldr` at `0x1000003c4`; `COPY, STORE` for the global `str` at `0x1000003dc`; and `COPY, RETURN` for the return at `0x100000408`. The indirect `ldr` at `0x100000400` had the same instruction bytes (`000140b9`) and identical instruction-local p-code operations as the global load at `0x1000003c4`. Its address register has a different preceding origin, not visible from that single-instruction observation. Each response reported `stop_reason: instruction_limit`, so no function-level coverage is implied. Target SHA-256 remained `64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7`. This concrete contrast supports exposing memory-op observations with their scope and provenance if they answer an analyst's question, while requiring separate data-flow or xref evidence for a target. It does not justify treating every `LOAD` as a global read, inventing a resolved object, or presenting instruction-local p-code as high-p-code def-use. ### Existing Ghidra instruction observation On the same fixture, real Ghidra 12.1.4 CLI `inspect-native-instruction` at `0x100000400` returned `status: decoded`, bytes `000140b9`, mnemonic `ldr`, and operand tokens `w0` and `[x8]`; its references were empty and `memory_addressing` was unavailable. The earlier Ghidra dossier and value trace separately identified a decompiler-derived memory-read effect and parameter use. Thus the existing instruction tool can expose the actual decoded instruction without inventing a destination, but this result does not itself provide a typed memory-read effect or the parameter-to-load data flow. Kuna's raw p-code control above is likewise instruction-local, though it explicitly includes a `LOAD` operation. The target SHA-256 remained `64acc2d130f29358567f75185e430de7a457a2d2cd0f0cbf22dbc379a4cac2e7`. No comparative latency, memory, token or completeness measurement was performed.

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:11:25 +00:00

bsakaguchi commented

2026-11-01 21:11:25 +00:00

Author

Owner

@morluto commented on GitHub (Oct 30, 2026):

A second, source-owned and unexecuted x86-64 ELF fixture (SHA-256 6e9cdb0df29fb22954750189e0fcf669819c89961b832506091b108debcde0a5) provides a positive read-kind case. Its increment reads global_counter.

Direct Kuna 1.986 xrefs --from increment --kind read,write --json returned one read from 0x13aa to 0x34a0, with instruction MOV ECX,dword ptr [0x34a0] and to_function: null.
In the real REA/Ghidra 12.1.4 MCP session for the same ELF, procedure_references returned a READ from 0x1013aa to 0x1034a0 plus stack references. The provider address coordinates differ from Kuna's; these are not interchangeable raw addresses.
REA/Kuna returned capability_unavailable for procedure_references; its pseudocode for increment was available and showed the global name.

This supports investigating the existing analyst question across both architectures, but neither two fixtures nor a matching instruction string establish exhaustive reference coverage or a universal address mapping. The arm64 address-forming data observation and this x86-64 read observation remain distinct kinds.

An additional source-owned, unexecuted x86-64 ELF (SHA-256 9e3bdc3fd0590d0074fcf3b51ca12b8c7fd361e99d1f44b1d6ac01c1382f8245) separates load, store, and branch functions. Direct Kuna --from reported read for audit_get and write for audit_set at the source global address; real REA/Ghidra procedure_references reported corresponding READ and WRITE edges in its own image coordinates. Both REA providers reported the two callees of audit_branch. Ghidra's outgoing references additionally included internal conditional and unconditional jumps, while direct Kuna --from audit_branch --kind jump returned zero. The difference is an observed coverage/semantic difference for this fixture, not proof either provider is generally complete or incorrect.

@morluto commented on GitHub (Oct 30, 2026): A second, source-owned and unexecuted x86-64 ELF fixture (SHA-256 `6e9cdb0df29fb22954750189e0fcf669819c89961b832506091b108debcde0a5`) provides a positive read-kind case. Its `increment` reads `global_counter`. - Direct Kuna 1.986 `xrefs --from increment --kind read,write --json` returned one `read` from `0x13aa` to `0x34a0`, with instruction `MOV ECX,dword ptr [0x34a0]` and `to_function: null`. - In the real REA/Ghidra 12.1.4 MCP session for the same ELF, `procedure_references` returned a `READ` from `0x1013aa` to `0x1034a0` plus stack references. The provider address coordinates differ from Kuna's; these are not interchangeable raw addresses. - REA/Kuna returned `capability_unavailable` for `procedure_references`; its pseudocode for `increment` was available and showed the global name. This supports investigating the existing analyst question across both architectures, but neither two fixtures nor a matching instruction string establish exhaustive reference coverage or a universal address mapping. The arm64 address-forming `data` observation and this x86-64 `read` observation remain distinct kinds. An additional source-owned, unexecuted x86-64 ELF (SHA-256 `9e3bdc3fd0590d0074fcf3b51ca12b8c7fd361e99d1f44b1d6ac01c1382f8245`) separates load, store, and branch functions. Direct Kuna `--from` reported `read` for `audit_get` and `write` for `audit_set` at the source global address; real REA/Ghidra `procedure_references` reported corresponding READ and WRITE edges in its own image coordinates. Both REA providers reported the two callees of `audit_branch`. Ghidra's outgoing references additionally included internal conditional and unconditional jumps, while direct Kuna `--from audit_branch --kind jump` returned zero. The difference is an observed coverage/semantic difference for this fixture, not proof either provider is generally complete or incorrect.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 30, 2026):

A controlled x86-64 ELF distinguishes the operand slot from the computed call target. Its unexecuted audit_refs forms the address of a global, reads it, writes it, makes a direct call, calls indirectly through a writable pointer initialized to the same function, and has a conditional branch. Independent LLVM disassembly confirms the instruction sites; the file digest stayed unchanged.

Direct Kuna 1.986 xrefs --from audit_refs produced data, read, and write observations for the global, one call to the function, and one call from the indirect instruction to the pointer slot, with to_function: null. --to the slot returned that same source; --to the callee returned only the direct call. The jump filter returned no edges despite the conditional jump in the disassembly.
Real REA/Ghidra 12.1.4 procedure_references returned separate READ to the pointer slot and COMPUTED_CALL to the function at the indirect site; resolve_native_call_targets classified the latter as a provider-reference resolved-indirect. inspect_native_instruction separately retained the read and computed call. These are static analysis observations, not proof the writable pointer has that value at runtime.
REA/Kuna procedure_references, typed instruction and call-target queries were capability unavailable. xrefs to the pointer returned the source address, without the upstream edge kind. The function's call graph reported the separately direct callee and partial coverage for unresolved indirect targets.

A second unexecuted ELF isolates a populated writable slot, a zero slot, and a register-indirect call. Direct Kuna reported a call to each slot with to_function:null, and zero xrefs for the register-indirect call. REA/Kuna returned an empty callee list with partial coverage for all three; it did not infer absence. REA/Ghidra resolved the populated-slot call to a static candidate, and marked the zero-slot and register calls unresolved with partial coverage. This is one architecture and two constructed ELF fixtures, not a general accuracy estimate. It demonstrates why a shared contract should not automatically reinterpret a Kuna call to a data address as a function-to-function edge or turn an empty upstream list into proof of no call.

@morluto commented on GitHub (Oct 30, 2026): A controlled x86-64 ELF distinguishes the operand slot from the computed call target. Its unexecuted `audit_refs` forms the address of a global, reads it, writes it, makes a direct call, calls indirectly through a writable pointer initialized to the same function, and has a conditional branch. Independent LLVM disassembly confirms the instruction sites; the file digest stayed unchanged. - Direct Kuna 1.986 `xrefs --from audit_refs` produced `data`, `read`, and `write` observations for the global, one `call` to the function, and one `call` from the indirect instruction to **the pointer slot**, with `to_function: null`. `--to` the slot returned that same source; `--to` the callee returned only the direct call. The `jump` filter returned no edges despite the conditional jump in the disassembly. - Real REA/Ghidra 12.1.4 `procedure_references` returned separate `READ` to the pointer slot and `COMPUTED_CALL` to the function at the indirect site; `resolve_native_call_targets` classified the latter as a provider-reference `resolved-indirect`. `inspect_native_instruction` separately retained the read and computed call. These are static analysis observations, not proof the writable pointer has that value at runtime. - REA/Kuna `procedure_references`, typed instruction and call-target queries were capability unavailable. `xrefs` to the pointer returned the source address, without the upstream edge kind. The function's call graph reported the separately direct callee and partial coverage for unresolved indirect targets. A second unexecuted ELF isolates a populated writable slot, a zero slot, and a register-indirect call. Direct Kuna reported a `call` to each slot with `to_function:null`, and zero xrefs for the register-indirect call. REA/Kuna returned an empty callee list **with partial coverage** for all three; it did not infer absence. REA/Ghidra resolved the populated-slot call to a static candidate, and marked the zero-slot and register calls unresolved with partial coverage. This is one architecture and two constructed ELF fixtures, not a general accuracy estimate. It demonstrates why a shared contract should not automatically reinterpret a Kuna `call` to a data address as a function-to-function edge or turn an empty upstream list into proof of no call.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

The previously noted apparent self-data row now has a reduced control and an upstream report: Kuna #1334.

In a self-built arm64 Mach-O containing only two direct bl calls (one backwards, one forwards) and returns, direct Kuna 1.986 and source-built upstream main both returned the two correct call rows and a data row from each bl address to itself. --kind call excluded the extra rows. The same real REA/Kuna MCP session returned each call site's own address when asked xrefs at that address; REA/Ghidra returned no incoming references to those two sites. Both providers returned the correct two callees. Thus the extra upstream rows are also visible through REA's existing incoming-address projection, which does not expose the upstream kind.

Independent LLVM disassembly confirmed the instruction targets. This is one small static fixture, not evidence that all self references are wrong or that REA should filter them by shape; the upstream issue keeps the root cause unverified. Target SHA-256 was unchanged and the binary was not executed.

@morluto commented on GitHub (Oct 31, 2026): The previously noted apparent self-data row now has a reduced control and an upstream report: [Kuna #1334](https://github.com/Noelo-Lab/kuna/issues/1334). In a self-built arm64 Mach-O containing only two direct `bl` calls (one backwards, one forwards) and returns, direct Kuna 1.986 and source-built upstream main both returned the two correct `call` rows **and** a `data` row from each `bl` address to itself. `--kind call` excluded the extra rows. The same real REA/Kuna MCP session returned each call site's own address when asked `xrefs` at that address; REA/Ghidra returned no incoming references to those two sites. Both providers returned the correct two callees. Thus the extra upstream rows are also visible through REA's existing incoming-address projection, which does not expose the upstream kind. Independent LLVM disassembly confirmed the instruction targets. This is one small static fixture, not evidence that all self references are wrong or that REA should filter them by shape; the upstream issue keeps the root cause unverified. Target SHA-256 was unchanged and the binary was not executed.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Cross-architecture control for the Kuna self-row observation: on a separately compiled, unexecuted x86-64 ELF with backward and forward direct calls, Kuna 1.986 and source-built upstream main returned the two expected call rows with no call-site self-data rows. Real REA/Kuna MCP likewise returned no incoming xrefs for either call site and retained both callees. This is a negative control for one instruction/format combination, not a general reason to filter self references.

The comparison also shows why address-only xref interpretation needs care: REA/Ghidra returned an incoming DATA reference to the first call site from 0x200018, not a self row. REA mapped that source to original file offset 24 and read 2611200000000000, the independently verified little-endian ELF entry address 0x201126; the typed reference had no containing source procedure. Ghidra returned no incoming reference for the second call site and both providers retained both callees. This is one header-metadata observation, not a runtime call or exhaustive comparison. See Kuna #1334 for source-build conditions. Target SHA-256 remained unchanged and the target was not executed.

@morluto commented on GitHub (Oct 31, 2026): Cross-architecture control for the Kuna self-row observation: on a separately compiled, unexecuted x86-64 ELF with backward and forward direct calls, Kuna 1.986 and source-built upstream main returned the two expected call rows with no call-site self-data rows. Real REA/Kuna MCP likewise returned no incoming xrefs for either call site and retained both callees. This is a negative control for one instruction/format combination, not a general reason to filter self references. The comparison also shows why address-only xref interpretation needs care: REA/Ghidra returned an incoming `DATA` reference to the first call site from `0x200018`, not a self row. REA mapped that source to original file offset 24 and read `2611200000000000`, the independently verified little-endian ELF entry address `0x201126`; the typed reference had no containing source procedure. Ghidra returned no incoming reference for the second call site and both providers retained both callees. This is one header-metadata observation, not a runtime call or exhaustive comparison. See [Kuna #1334](https://github.com/Noelo-Lab/kuna/issues/1334#issuecomment-6544115739) for source-build conditions. Target SHA-256 remained unchanged and the target was not executed.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A bounded control for consuming incoming references rather than treating every address as a caller: on REA 2d5dec26c31662764c9adfe3ff996174901b8d49, a source-owned arm64 Mach-O has _audit_entry beginning with bl _audit_leaf at 0x2c8 and _audit_wrapper calling it at 0x2d0. Both real Ghidra 12.1.4 and Kuna 1.986 procedure_callers reported only the wrapper; both procedure_callees reported the leaf, and forward/backward trace_call_path reached the expected endpoints. Kuna xrefs(0x2c8) returned [0x2d0], with no self row in this fixture. CLI rea xrefs agreed with MCP for both providers.

Ghidra xrefs(0x2c8) returned [0x2d0, 0x406a]. Its typed procedure_references(direction: incoming) classified the first as UNCONDITIONAL_CALL from the wrapper and the latter as DATA with no source procedure. inspect_native_instruction(0x406a) reported data; inspect_native_load_image placed it in the loaded, non-executable __LINKEDIT mapping. Thus the extra row is not established as an executable caller. trace_feature preserved its not_in_procedure containment result. These provider observations do not justify removing non-code references or assuming every address-only xref is a call.

A second similar fixture with a NOP before the call also had no Kuna self row at the interior BL. These are negative controls against the previously reported self-xref issue, not evidence that the symptom is fixed generally. Successful MCP responses passed SDK compact schema validation; both source-owned fixtures remained unchanged and unexecuted. Related upstream Noelo-Lab/kuna#1334.

@morluto commented on GitHub (Oct 31, 2026): A bounded control for consuming incoming references rather than treating every address as a caller: on REA `2d5dec26c31662764c9adfe3ff996174901b8d49`, a source-owned arm64 Mach-O has `_audit_entry` beginning with `bl _audit_leaf` at `0x2c8` and `_audit_wrapper` calling it at `0x2d0`. Both real Ghidra 12.1.4 and Kuna 1.986 `procedure_callers` reported only the wrapper; both `procedure_callees` reported the leaf, and forward/backward `trace_call_path` reached the expected endpoints. Kuna `xrefs(0x2c8)` returned `[0x2d0]`, with no self row in this fixture. CLI `rea xrefs` agreed with MCP for both providers. Ghidra `xrefs(0x2c8)` returned `[0x2d0, 0x406a]`. Its typed `procedure_references(direction: incoming)` classified the first as `UNCONDITIONAL_CALL` from the wrapper and the latter as `DATA` with no source procedure. `inspect_native_instruction(0x406a)` reported `data`; `inspect_native_load_image` placed it in the loaded, non-executable `__LINKEDIT` mapping. Thus the extra row is not established as an executable caller. `trace_feature` preserved its `not_in_procedure` containment result. These provider observations do not justify removing non-code references or assuming every address-only xref is a call. A second similar fixture with a NOP before the call also had no Kuna self row at the interior BL. These are negative controls against the previously reported self-xref issue, not evidence that the symptom is fixed generally. Successful MCP responses passed SDK compact schema validation; both source-owned fixtures remained unchanged and unexecuted. Related upstream Noelo-Lab/kuna#1334.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

The earlier negative self-xref controls can be explained more narrowly: an identical arm64 instruction sequence linked at 0x2cc produced only the real call, but linked at 0x12cc produced both that call and a self-data reference with Kuna 1.986. A logging-only upstream build tied the difference to the data-reference scanner's 4096 value floor and an INT_ADD(call_site, 4) operand; see Noelo-Lab/kuna#1334.

Real REA/Kuna on the high-address control returned the self address from xrefs(0x12cc), while procedure_callers and procedure_callees still retained the authored wrapper/leaf relationships. The low-address control did not return the self row. Both fixtures and target hashes were unchanged; no target was executed. This supports preserving the typed origin and coverage instead of silently discarding all self-references in REA.

@morluto commented on GitHub (Oct 31, 2026): The earlier negative self-xref controls can be explained more narrowly: an identical arm64 instruction sequence linked at `0x2cc` produced only the real call, but linked at `0x12cc` produced both that call and a self-data reference with Kuna 1.986. A logging-only upstream build tied the difference to the data-reference scanner's 4096 value floor and an `INT_ADD(call_site, 4)` operand; see Noelo-Lab/kuna#1334. Real REA/Kuna on the high-address control returned the self address from `xrefs(0x12cc)`, while `procedure_callers` and `procedure_callees` still retained the authored wrapper/leaf relationships. The low-address control did not return the self row. Both fixtures and target hashes were unchanged; no target was executed. This supports preserving the typed origin and coverage instead of silently discarding all self-references in REA.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A new arm64 control shows why the source-reference contract needs both provenance and coverage rather than assuming either provider reports every address-forming operation. On REA 60149282fcfc05ac32fbc94434c107710120da6f, an owned Mach-O has three ADR functions: one returns its own instruction address (0x12c0), one returns the following instruction (0x12cc), and one returns an address two instructions ahead (0x12d8). otool independently decoded the immediates; no target was executed.

Real REA/Kuna 1.986 xrefs found the self and two-ahead sources but returned no source for 0x12cc; procedure_references remained explicitly unavailable. Real REA/Ghidra 12.1.4 found the self source but not the latter two via xrefs. Ghidra inspect_native_instruction nevertheless decoded adr x0,0x12cc, and trace_native_values showed a COPY of 0x12cc flowing to RETURN; the same pattern held for 0x12d8. These are static address values, not proof of a memory read or runtime execution. Successful MCP calls passed the SDK compact-schema check; the fixture hash was unchanged.

For Kuna, a logging-only upstream build confirmed that its fall-through-value suppression removes the next-instruction CPUI_COPY; I opened Noelo-Lab/kuna#1360. A blanket filter for self-address rows would also remove the valid first control. This sample does not establish why Ghidra omitted the other two references or how common either case is.

@morluto commented on GitHub (Oct 31, 2026): A new arm64 control shows why the source-reference contract needs both provenance and coverage rather than assuming either provider reports every address-forming operation. On REA `60149282fcfc05ac32fbc94434c107710120da6f`, an owned Mach-O has three `ADR` functions: one returns its own instruction address (`0x12c0`), one returns the following instruction (`0x12cc`), and one returns an address two instructions ahead (`0x12d8`). `otool` independently decoded the immediates; no target was executed. Real REA/Kuna 1.986 `xrefs` found the self and two-ahead sources but returned no source for `0x12cc`; `procedure_references` remained explicitly unavailable. Real REA/Ghidra 12.1.4 found the self source but not the latter two via xrefs. Ghidra `inspect_native_instruction` nevertheless decoded `adr x0,0x12cc`, and `trace_native_values` showed a `COPY` of `0x12cc` flowing to `RETURN`; the same pattern held for `0x12d8`. These are static address values, not proof of a memory read or runtime execution. Successful MCP calls passed the SDK compact-schema check; the fixture hash was unchanged. For Kuna, a logging-only upstream build confirmed that its fall-through-value suppression removes the next-instruction `CPUI_COPY`; I opened Noelo-Lab/kuna#1360. A blanket filter for self-address rows would also remove the valid first control. This sample does not establish why Ghidra omitted the other two references or how common either case is.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Upstream fix control relevant to this issue: I compared current Kuna main cbfa8414 with the same source plus open Kuna PR #1356, using real REA main 60149282 stdio MCP. Both source builds reported 0.1.0 and REA correctly marked verified_release: false; both used a separately supplied 1.986 compiled SLEIGH tree.

On the rebuilt REA verifier Mach-O, main returned the four known self-xref rows at BL sites; the PR build returned none. The actual call target's incoming xref, four direct callees, and a reached path to the checksum function remained. On the separate AArch64 ADR x0, . control, both builds retained the legitimate self-reference. The separate next-instruction ADR case remained absent (upstream #1360). Targets were unchanged and unexecuted. This is a local two-fixture control, not a released-provider upgrade or a reason for REA to drop self-edges itself.

@morluto commented on GitHub (Oct 31, 2026): Upstream fix control relevant to this issue: I compared current Kuna main `cbfa8414` with the same source plus open [Kuna PR #1356](https://github.com/Noelo-Lab/kuna/pull/1356), using real REA main `60149282` stdio MCP. Both source builds reported `0.1.0` and REA correctly marked `verified_release: false`; both used a separately supplied 1.986 compiled SLEIGH tree. On the rebuilt REA verifier Mach-O, main returned the four known self-xref rows at `BL` sites; the PR build returned none. The actual call target's incoming xref, four direct callees, and a reached path to the checksum function remained. On the separate AArch64 `ADR x0, .` control, both builds retained the legitimate self-reference. The separate next-instruction `ADR` case remained absent (upstream #1360). Targets were unchanged and unexecuted. This is a local two-fixture control, not a released-provider upgrade or a reason for REA to drop self-edges itself.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A local upstream diagnostic experiment narrows the separate next-instruction ADR gap: after PR #1356, restricting fall-through data suppression to lifted instructions containing a call recovered the 0x12c8 → 0x12cc data reference in direct Kuna and in REA's xrefs(0x12cc). In the same checked fixtures, the legitimate ADR x0, . reference, direct call target, callees and reached path remained; separate x86-64 and AArch64 call-return controls did not gain a return-address reference.

This one-line source change is not submitted or broadly validated. The upstream targeted test compilation was stopped for resource use before it completed, and the existing synthetic return-address test needs attention if such a condition is adopted. Both REA sessions used source-built Kuna 0.1.0, correctly marked unverified, with a supplied 1.986 SLEIGH tree. Target hashes stayed unchanged; no targets executed. Details and limitations: https://github.com/Noelo-Lab/kuna/issues/1360#issuecomment-6546674583.

@morluto commented on GitHub (Oct 31, 2026): A local upstream diagnostic experiment narrows the separate next-instruction `ADR` gap: after PR #1356, restricting fall-through data suppression to lifted instructions containing a call recovered the `0x12c8 → 0x12cc` data reference in direct Kuna and in REA's `xrefs(0x12cc)`. In the same checked fixtures, the legitimate `ADR x0, .` reference, direct call target, callees and reached path remained; separate x86-64 and AArch64 call-return controls did not gain a return-address reference. This one-line source change is not submitted or broadly validated. The upstream targeted test compilation was stopped for resource use before it completed, and the existing synthetic return-address test needs attention if such a condition is adopted. Both REA sessions used source-built Kuna `0.1.0`, correctly marked unverified, with a supplied 1.986 SLEIGH tree. Target hashes stayed unchanged; no targets executed. Details and limitations: https://github.com/Noelo-Lab/kuna/issues/1360#issuecomment-6546674583.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Additional independent ARM64 Mach-O control on REA d54a4661da20382ad8456564a08569fdd24131c5:

_main:
  adrp x8, _audit_global@PAGE
  add  x8, x8, _audit_global@PAGEOFF
  ldr  w9, [x8]
  add  w9, w9, #1
  str  w9, [x8]
  mov  x0, x8
  ret

Ghidra 12.1.4 through REA reports READ at 0x100000378, WRITE at 0x100000380, and DATA at 0x100000384 to the global 0x100004000 in both incoming instruction context and outgoing function references. The raw xrefs list is untyped, as advertised. These are static observations, not proof of execution.
Verified Kuna 1.986 direct xrefs --from _main and --to 0x100004000 report only a data reference at the address-forming adrp (0x100000370); REA/Kuna returns that address and correctly reports typed instructions and procedure_references unavailable. trace_native_values reports no provider def-use model, not an empty complete value flow.
An unverified current-source build (8c74a944d74f8d3349755e05441a9628b4753111) directly reports the data, read and write rows; REA/Kuna returns their three source addresses but not their kinds, and still reports typed instruction/function references unavailable. This is an observation about that source build, not a released-version guarantee or a recommendation to add compatibility code.

A separate decompilation detail is relevant when comparing providers: verified Kuna 1.986 produced return audit_global in both its direct single decompile and REA's completed project export, whereas Ghidra and the unverified current Kuna source produced a return of the global's address. In the static instructions x0 receives x8, which holds the address after adrp/add; w9 holds the loaded/updated value. This is an observed release-vs-source pseudocode difference on this fixture, not a runtime test or a claim that either decompiler's text is generally authoritative. The current-source output already agrees here, so this example alone does not establish an open upstream HEAD bug.

The fixture was not executed and its SHA-256 9b1f167a30cd17cb5d4393d720336fc14d7ac3bce20ade06182b941ecf8918fd was unchanged. One fixture does not establish complete reference coverage; preserving address formation, reads, writes, provider provenance and unknowns remains essential.

@morluto commented on GitHub (Oct 31, 2026): Additional independent ARM64 Mach-O control on REA `d54a4661da20382ad8456564a08569fdd24131c5`: ```asm _main: adrp x8, _audit_global@PAGE add x8, x8, _audit_global@PAGEOFF ldr w9, [x8] add w9, w9, #1 str w9, [x8] mov x0, x8 ret ``` - Ghidra 12.1.4 through REA reports `READ` at `0x100000378`, `WRITE` at `0x100000380`, and `DATA` at `0x100000384` to the global `0x100004000` in both incoming instruction context and outgoing function references. The raw `xrefs` list is untyped, as advertised. These are static observations, not proof of execution. - Verified Kuna 1.986 direct `xrefs --from _main` and `--to 0x100004000` report only a `data` reference at the address-forming `adrp` (`0x100000370`); REA/Kuna returns that address and correctly reports typed instructions and `procedure_references` unavailable. `trace_native_values` reports no provider def-use model, not an empty complete value flow. - An **unverified** current-source build (`8c74a944d74f8d3349755e05441a9628b4753111`) directly reports the `data`, `read` and `write` rows; REA/Kuna returns their three source addresses but not their kinds, and still reports typed instruction/function references unavailable. This is an observation about that source build, not a released-version guarantee or a recommendation to add compatibility code. A separate decompilation detail is relevant when comparing providers: verified Kuna 1.986 produced `return audit_global` in both its direct single decompile and REA's completed project export, whereas Ghidra and the unverified current Kuna source produced a return of the global's **address**. In the static instructions `x0` receives `x8`, which holds the address after `adrp/add`; `w9` holds the loaded/updated value. This is an observed release-vs-source pseudocode difference on this fixture, not a runtime test or a claim that either decompiler's text is generally authoritative. The current-source output already agrees here, so this example alone does not establish an open upstream HEAD bug. The fixture was not executed and its SHA-256 `9b1f167a30cd17cb5d4393d720336fc14d7ac3bce20ade06182b941ecf8918fd` was unchanged. One fixture does not establish complete reference coverage; preserving address formation, reads, writes, provider provenance and unknowns remains essential.

bsakaguchi commented

2026-11-01 21:11:26 +00:00

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

A cross-provider immediate-constant control for this design, on REA main 6e9ee97a, macOS arm64, real Kuna 1.986 and Ghidra 12.1.4, with MCP SDK 2.3.1 compact-schema validation:

An owned, unexecuted dylib has _audit_scalar at 0x12a8: mov w0, #0x12b0; ret. The immediate coincides with _audit_target at 0x12b0; the instruction itself does not load memory or call that function. Direct Kuna xrefs --from _audit_scalar and --to 0x12b0 returned a data row between them. Ghidra procedure_references also returned a DATA reference to that address, and inspect_native_instruction separately reported an immediate operand, fallthrough and no call/jump/read/write on the reference. A caller might interpret the returned numeric value later; these static observations do not establish its downstream use.

REA/Kuna xrefs(0x12b0) returned source 0x12a8; procedure_references and typed instruction inspection were unavailable. trace_feature("audit_target") retained that source with an unavailable containing-procedure outcome. REA/Ghidra retained the same source plus a separate metadata reference, and resolved the source procedure. Both feature traces survived Evidence export/import into fresh target-free servers with equal normalized results and limitations. The target hash remained 88599b046794dea3a1035049f01d0ecebc683fd34f4dc3367e63b9a0ba89e784; no target was executed.

This is not proof either provider violates its contract: an address-valued constant can be meaningful. It is a control for the shared UX decision: a data reference should not by itself be promoted into an observed memory access or runtime relationship, and preserving typed instruction/reference evidence where available helps an analyst assess the candidate. No broad false-positive rate or autonomous-agent behavior was measured. An unpadded low-address control returned no Kuna rows; I added it as a threshold counterexample to Noelo-Lab/kuna#1364 rather than filing a duplicate.

@morluto commented on GitHub (Nov 1, 2026): A cross-provider immediate-constant control for this design, on REA main `6e9ee97a`, macOS arm64, real Kuna 1.986 and Ghidra 12.1.4, with MCP SDK 2.3.1 compact-schema validation: An owned, unexecuted dylib has `_audit_scalar` at `0x12a8`: `mov w0, #0x12b0; ret`. The immediate coincides with `_audit_target` at `0x12b0`; the instruction itself does not load memory or call that function. Direct Kuna `xrefs --from _audit_scalar` and `--to 0x12b0` returned a `data` row between them. Ghidra `procedure_references` also returned a `DATA` reference to that address, and `inspect_native_instruction` separately reported an immediate operand, fallthrough and no call/jump/read/write on the reference. A caller might interpret the returned numeric value later; these static observations do not establish its downstream use. REA/Kuna `xrefs(0x12b0)` returned source `0x12a8`; `procedure_references` and typed instruction inspection were unavailable. `trace_feature("audit_target")` retained that source with an unavailable containing-procedure outcome. REA/Ghidra retained the same source plus a separate metadata reference, and resolved the source procedure. Both feature traces survived Evidence export/import into fresh target-free servers with equal normalized results and limitations. The target hash remained `88599b046794dea3a1035049f01d0ecebc683fd34f4dc3367e63b9a0ba89e784`; no target was executed. This is not proof either provider violates its contract: an address-valued constant can be meaningful. It is a control for the shared UX decision: a `data` reference should not by itself be promoted into an observed memory access or runtime relationship, and preserving typed instruction/reference evidence where available helps an analyst assess the candidate. No broad false-positive rate or autonomous-agent behavior was measured. An unpadded low-address control returned no Kuna rows; I added it as a threshold counterexample to Noelo-Lab/kuna#1364 rather than filing a duplicate.

bsakaguchi referenced this issue

2026-11-01 21:47:38 +00:00

[PR #6761] [CLOSED] fix(execution): exclude discarded POST bodies from request metadata accounting #7408

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 00:29:39 +00:00

bsakaguchi added

enhancement

and removed