Multiple ELFIO copies across TheRock and rocm-systems: can we remove TheRock's third-party/elfio? #8972

Summary

ELFIO (the header-only ELF reader/writer from serge1/ELFIO) is currently checked out and built in several places across TheRock and rocm-systems, at different versions. A recent set of robustness fixes for ELFIO had to be made in four separate places, and the TheRock copy turns out to have no consumers. This issue describes the current state and asks maintainers whether TheRock should keep, complete, or drop its ELFIO dependency.

Current state

Details:

• TheRock's ELFIO is not used by any subproject. #4258 added it so profiler tools could use a single, centrally patched copy, but no subproject switched over. rocprofiler-sdk still builds its own submodule (ROCPROFILER_BUILD_ELFIO defaults to ON), in standalone builds and in TheRock builds alike.

• What TheRock's copy does today:

  • BUILD_TOPOLOGY.toml lists elfio in rocprofiler-sdk's artifact_deps, but the SDK doesn't use it. Its only visible effect is that CI jobs download the ELFIO artifacts.
  • The ELFIO headers are shipped in the amdrocm-sysdeps deb/rpm package, and #7191 proposes adding them to the rocm-sdk-devel wheel (#6156). In [Issue]: Missing items in pip install vs package manager install #6156 it was already asked whether there is a business need to ship ELFIO; none has been identified so far.

• rocprofiler-sdk's use is private. ELFIO is header-only and used only at build time. The SDK's installed CMake config and public headers don't reference it, so nothing built against an installed rocprofiler-sdk needs ELFIO.

• The versions differ in ways that matter. TheRock's 3.12 is older than the SDK's submodule. 575bfdb includes loader hardening that 3.12 lacks:

  • 7a1de75: use-after-free on corrupted sections
  • 52f21a1: overflow fixes in string and section handling
  • 92b9b67 and a428b72: stream-size and file-offset checks

  Switching the SDK to TheRock's ELFIO as-is (#8395) would therefore be a partial downgrade.

What prompted this

We fixed out-of-bounds reads and unbounded loops in ELFIO's symbol hash table lookup and note parsing (SWSPLAT-24296, SWSPLAT-24318). Because of the copies above, the same fixes currently live in four places:

Plus #8395 to route the SDK through TheRock's copy.

These fixes are the first case, but the next upstream ELFIO issue will have the same fan-out.

The main constraint is upstream's pace. ELFIO has had no tagged release since 3.12, and external PRs can wait a long time for review: #173/#174 have been open since 2026-08-31 without review, and their CI still needs maintainer approval. So "fix upstream, then bump everywhere" isn't a workable way to ship security-relevant fixes. Downstream copies need to carry patches until upstream merges and, ideally, tags a release.

Proposal

Drop ELFIO from TheRock, and keep it as a private, patched dependency of the rocm-systems components that use it:

1. Remove the following from TheRock:
   • third-party/elfio
   • patches/third-party/elfio/
   • the elfio artifact and its packaging entry in amdrocm-sysdeps
   • elfio from rocprofiler-sdk's artifact_deps
2. Close [SWSPLAT-24296] Backport ELFIO hash table bounds validation #7772, [SWSPLAT-24318] Backport ELFIO note bounds validation #7773 and rocprofiler-sdk: Use TheRock's ELFIO package #8395, and resolve fix(packaging): include elfio dev artifact in rocm-sdk-devel wheel #7191 and [Issue]: Missing items in pip install vs package manager install #6156 as "ELFIO is not shipped".
3. In rocm-systems:
   • rocprofiler-sdk: carry the fixes as patches on its ELFIO submodule. Because the SDK uses this submodule in both standalone and TheRock builds, one change covers both. ROCm/rocm-systems#13363 does this. It moves the submodule to upstream main (the base of the upstream PRs), so the patches are the upstream changes verbatim, and applies them at configure time to a copy of the headers in the build tree, leaving the submodule unmodified.
   • CLR: keep its patched fork; it can't take upstream ELFIO directly.

Result: an upstream ELFIO fix needs to land in at most three places (upstream, rocprofiler-sdk, CLR) instead of four. Nothing in TheRock has to be kept in sync, and rocm-systems stays buildable without TheRock.

Alternative: complete the centralization from #4258

Keep TheRock's ELFIO and make it the copy that rocprofiler-sdk uses in TheRock builds:

• move the pin beyond 3.12 (a new tarball mirrored to S3);
• keep carrying the patches;
• land rocprofiler-sdk: Use TheRock's ELFIO package #8395.

This doesn't remove the SDK's submodule, because standalone rocm-systems builds still need it. The result is two copies of the SDK's ELFIO (TheRock and the submodule) to keep at the same version and patch level indefinitely.

Questions for maintainers

1. Is there a consumer or business need for shipping ELFIO headers in amdrocm-sysdeps (and in the wheels, per fix(packaging): include elfio dev artifact in rocm-sdk-devel wheel #7191)? If not, are you OK with removing third-party/elfio and its artifact and packaging entries?
2. If TheRock should keep ELFIO, is moving the pin past 3.12 acceptable? That means mirroring a newer upstream commit to S3, since there's no newer release.
3. What's the preferred way for rocm-systems components to carry patches against third-party submodules until upstream merges? Options:
   • patch files applied at configure time;
   • a ROCm-owned fork (e.g. ROCm/ELFIO) that the submodule points to;
   • something else.
4. Are there other ELFIO consumers in the wider ROCm build that we've missed? We checked TheRock's consumer graph, BUILD_TOPOLOGY.toml and packaging, and all of rocm-systems.

Prepared with AI assistance.