[GH-ISSUE #7235] [Feature] Decode FDO packaging and dlopen metadata in inspect-elf-notes #4310

New issue

Open

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

bsakaguchi commented

2026-10-31 00:48:48 +00:00

Owner

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

Before submitting

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

Area

Native analysis or decompilation

Current limitation

inspect-elf-notes names and decodes only GNU notes. FDO notes come back as type_name: "unknown" with gnu: null, and their descriptors are longer than the 64-byte hex preview, so descriptor.hex is null too. The result keeps only a SHA-256 and a file range, not the content.

These notes declare which package a binary came from (.note.package) and which libraries it may dlopen at runtime (.note.dlopen). Both are defined by UAPI group specifications, and readelf -n decodes them:

$ readelf -n /usr/bin/ls
  FDO                  0x0000007c	FDO_PACKAGING_METADATA
    Packaging Metadata: {"type":"rpm","name":"coreutils","version":"9.10-5.fc44","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:44"}

rea inspect-elf-notes /usr/bin/ls --json on main (4ca3032e7) reports the same note as:

{ "owner": "FDO", "type": 3405650558, "type_name": "unknown",
  "descriptor": { "bytes": 124, "sha256": "43e42236…", "hex": null }, "gnu": null }

Use cases

Package provenance: an agent can name the package, version and distribution that shipped an ELF without a package database.
Dependency discovery: dlopen notes list optional libraries that DT_NEEDED does not show, for example libnss_myhostname.so.2 → libidn2.so.0 for the idn feature.

Observed frequency on one Fedora 44 x86_64 host: across 5,276 ELF files under /usr/bin and /usr/lib64 that inspect-elf-notes parses, there were 9,294 FDO packaging-metadata entries and 166 FDO dlopen-metadata entries (PT_NOTE and SHT_NOTE copies counted separately).

Desired outcome and success criteria

FDO type 0xcafe1a7e is named fdo_packaging_metadata and FDO type 0x407c0c0a is named fdo_dlopen_metadata. Type numbers are interpreted only within their owner's namespace.
Each entry carries the parsed JSON (an object for packaging, an array for dlopen) next to the existing gnu field.
A descriptor that breaks the spec (missing NUL terminator, non-NUL bytes after it, invalid UTF-8 or JSON, wrong top-level shape) keeps its entry, hash and location, and reports why the metadata is absent. It does not fail the inspection.
The result states that this metadata is a producer declaration that is not verified against a package database or loaded libraries.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Static parsing of descriptors that inspect-elf-notes already reads. No new inputs, no execution, no package-database lookup. Non-goal: validating individual keys against the specifications.

Verification available so far

I have a prototype or observed results

Verification details (optional)

Prototype on a branch (PR to follow):

Unit tests for both note kinds, PT_NOTE/SHT_NOTE repetition, each malformed-descriptor case and unknown FDO types; a public-CLI acceptance case; existing MCP boundary tests pass.
The sweep of the 5,276 host ELF files above decoded all 9,294 packaging and 166 dlopen entries with no issue. The same files parsed before and after the change.
rea inspect-elf-notes /usr/bin/ls --json returns the same coreutils JSON as readelf -n.

Alternatives considered

Raising the 64-byte hex preview limit: the agent still has to decode hex to JSON itself, and outputs grow for every large descriptor.
Running readelf -n separately: an extra tool, output outside Evidence provenance, and not available on every host.

Possible direction

Owner-scoped type naming in the domain contract, plus a per-descriptor FDO decoder in ElfNoteParser that decodes each file range once and charges the retained JSON text to the existing note text budget.

References

Package Metadata for Executable Files: owner FDO, type 0xcafe1a7e, NUL-terminated and NUL-padded UTF-8 JSON object
ELF dlopen metadata: owner FDO, type 0x407c0c0a, NUL-terminated UTF-8 JSON array of objects
Related prior work: #4837 (feat(elf): inspect PT_NOTE and SHT_NOTE tables)

Originally created by @AniketR10 on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7235 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [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 request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation `inspect-elf-notes` names and decodes only GNU notes. FDO notes come back as `type_name: "unknown"` with `gnu: null`, and their descriptors are longer than the 64-byte hex preview, so `descriptor.hex` is `null` too. The result keeps only a SHA-256 and a file range, not the content. These notes declare which package a binary came from (`.note.package`) and which libraries it may `dlopen` at runtime (`.note.dlopen`). Both are defined by UAPI group specifications, and `readelf -n` decodes them: ``` $ readelf -n /usr/bin/ls FDO 0x0000007c FDO_PACKAGING_METADATA Packaging Metadata: {"type":"rpm","name":"coreutils","version":"9.10-5.fc44","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:44"} ``` `rea inspect-elf-notes /usr/bin/ls --json` on `main` (`4ca3032e7`) reports the same note as: ```json { "owner": "FDO", "type": 3405650558, "type_name": "unknown", "descriptor": { "bytes": 124, "sha256": "43e42236…", "hex": null }, "gnu": null } ``` ### Use cases - Package provenance: an agent can name the package, version and distribution that shipped an ELF without a package database. - Dependency discovery: dlopen notes list optional libraries that `DT_NEEDED` does not show, for example `libnss_myhostname.so.2` → `libidn2.so.0` for the `idn` feature. Observed frequency on one Fedora 44 x86_64 host: across 5,276 ELF files under `/usr/bin` and `/usr/lib64` that `inspect-elf-notes` parses, there were 9,294 FDO packaging-metadata entries and 166 FDO dlopen-metadata entries (PT_NOTE and SHT_NOTE copies counted separately). ### Desired outcome and success criteria - FDO type `0xcafe1a7e` is named `fdo_packaging_metadata` and FDO type `0x407c0c0a` is named `fdo_dlopen_metadata`. Type numbers are interpreted only within their owner's namespace. - Each entry carries the parsed JSON (an object for packaging, an array for dlopen) next to the existing `gnu` field. - A descriptor that breaks the spec (missing NUL terminator, non-NUL bytes after it, invalid UTF-8 or JSON, wrong top-level shape) keeps its entry, hash and location, and reports why the metadata is absent. It does not fail the inspection. - The result states that this metadata is a producer declaration that is not verified against a package database or loaded libraries. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Static parsing of descriptors that `inspect-elf-notes` already reads. No new inputs, no execution, no package-database lookup. Non-goal: validating individual keys against the specifications. ### Verification available so far I have a prototype or observed results ### Verification details (optional) Prototype on a branch (PR to follow): - Unit tests for both note kinds, PT_NOTE/SHT_NOTE repetition, each malformed-descriptor case and unknown FDO types; a public-CLI acceptance case; existing MCP boundary tests pass. - The sweep of the 5,276 host ELF files above decoded all 9,294 packaging and 166 dlopen entries with no issue. The same files parsed before and after the change. - `rea inspect-elf-notes /usr/bin/ls --json` returns the same coreutils JSON as `readelf -n`. ### Alternatives considered - Raising the 64-byte hex preview limit: the agent still has to decode hex to JSON itself, and outputs grow for every large descriptor. - Running `readelf -n` separately: an extra tool, output outside Evidence provenance, and not available on every host. ### Possible direction Owner-scoped type naming in the domain contract, plus a per-descriptor FDO decoder in `ElfNoteParser` that decodes each file range once and charges the retained JSON text to the existing note text budget. ### References - [Package Metadata for Executable Files](https://uapi-group.org/specifications/specs/package_metadata_for_executable_files/): owner `FDO`, type `0xcafe1a7e`, NUL-terminated and NUL-padded UTF-8 JSON object - [ELF dlopen metadata](https://uapi-group.org/specifications/specs/elf_dlopen_metadata/): owner `FDO`, type `0x407c0c0a`, NUL-terminated UTF-8 JSON array of objects - Related prior work: #4837 (`feat(elf): inspect PT_NOTE and SHT_NOTE tables`)

bsakaguchi referenced this issue

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

[GH-ISSUE #8100] [Bug] Apple graph reports a null Info.plist for flattened macOS frameworks #4673

bsakaguchi referenced this issue

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

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