Skip to content

refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook - #2282

Open
gyuheon0h wants to merge 3 commits into
mainfrom
gyuheon0h/extract-got-hook-crate
Open

refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook#2282
gyuheon0h wants to merge 3 commits into
mainfrom
gyuheon0h/extract-got-hook-crate

Conversation

@gyuheon0h

@gyuheon0h gyuheon0h commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Stacked under feat(got-hook): add DT_HASH fallback, relocation type guard, and hook_symbol

What does this PR do?

Moves the ELF GOT-patching infrastructure out of libdd-profiling-heap-gotter into a new shared crate libdd-got-hook, so multiple crates can reuse the same machinery for runtime function interposition.

This is a pure code move. I tried to have no behavioral changes here.

What moves to libdd-got-hook

  • DynamicInfo::from_phdr: parse PT_DYNAMIC from a loaded ELF object
  • gnu_hash / gnu_hash_symbol_count / gnu_hash_lookup / check_sym: GNU hash table utilities
  • iterate_libraries: this is a dl_iterate_phdr wrapper with panic-safe trampoline
  • PageProtGuard / read_proc_maps / MapEntry: RELRO-aware page protection management
  • lookup_symbol / LookupResult: used for resolving a symbol across all loaded objects
  • elf64_r_sym: relocation info helper
  • ELF types and constants

What stays in libdd-profiling-heap-gotter

  • SymbolOverrides: multi-symbol registry
  • hooks.rs: the actual malloc/free/calloc/realloc hook functions
  • lib.rs: install_heap_overrides / update_heap_overrides public API

Motivation

What inspired you to submit this pull request?

Additional Notes

Gated on @scottgerring's approval

How to test the change?

Describe here in detail how the change can be validated.

gyuheon0h commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

@github-actions

github-actions Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 234 documentation warning(s) found

📦 libdd-gotter - 6 warning(s)

📦 libdd-profiling-heap-gotter - 55 warning(s)

📦 tools - 173 warning(s)


Updated: 2026-07-31 19:08:14 UTC | Commit: ad74a52 | missing-docs job results

@github-actions

github-actions Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

⚠️ 3 issue(s) found, showing only errors (advisories, bans, sources)

📦 libdd-gotter - ✅ No issues

📦 libdd-profiling-heap-gotter - ✅ No issues

📦 tools - 3 error(s)

Show output
error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v38.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v38.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:75:1
   │
75 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── tools v38.0.0

advisories FAILED, bans ok, sources ok

Updated: 2026-07-31 19:09:37 UTC | Commit: ad74a52 | dependency-check job results

@datadog-official

datadog-official Bot commented Jul 27, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 87.97%
Overall Coverage: 74.91% (-0.02%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 31e53ca | Docs | Datadog PR Page | Give us feedback!

@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 63b2fca to 60c1e60 Compare July 27, 2026 19:14
@gyuheon0h gyuheon0h changed the title refactor: extract shared GOT-patching primitives into libdd-got-hook refatcor(got-patching): extract shared GOT-patching primitives into libdd-got-hook Jul 27, 2026
@gyuheon0h gyuheon0h changed the title refatcor(got-patching): extract shared GOT-patching primitives into libdd-got-hook refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook Jul 27, 2026
@dd-octo-sts

dd-octo-sts Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 87.33 MB 87.33 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.01 MB 8.01 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.78 MB 10.78 MB 0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 98.59 MB 98.59 MB 0% (0 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 26.08 MB 26.08 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 89.60 KB 89.60 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 188.23 MB 188.23 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 980.23 MB 980.23 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.48 MB 8.48 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 89.60 KB 89.60 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 25.08 MB 25.08 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 49.90 MB 49.90 MB 0% (0 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 22.65 MB 22.65 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 91.00 KB 91.00 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 192.71 MB 192.71 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 971.14 MB 971.14 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.55 MB 6.55 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 91.00 KB 91.00 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 26.94 MB 26.94 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 47.50 MB 47.50 MB 0% (0 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 77.82 MB 77.82 MB 0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 8.93 MB 8.93 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 93.38 MB 93.38 MB 0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.87 MB 10.87 MB 0% (0 B) 👌

@gyuheon0h
gyuheon0h marked this pull request as ready for review July 27, 2026 20:00
@gyuheon0h
gyuheon0h requested review from a team as code owners July 27, 2026 20:00
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 822405c to 6ab7768 Compare July 27, 2026 20:01

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 822405c2e5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread libdd-got-hook/src/elf.rs Outdated
Comment thread libdd-got-hook/src/elf.rs Outdated
Comment thread libdd-got-hook/src/elf.rs Outdated
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 6ab7768 to 285cdd3 Compare July 27, 2026 20:06
@pr-commenter

pr-commenter Bot commented Jul 27, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-07-31 18:22:33

Comparing candidate commit 66e5b36 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit 7b8cb2a in branch main.

Found 17 performance improvements and 3 performance regressions! Performance is the same for 122 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:otlp/e2e_json/1x1000

  • 🟩 execution_time [-314.279µs; -304.951µs] or [-7.056%; -6.847%]

scenario:otlp/encode_json/1x1000

  • 🟩 execution_time [-296.348µs; -295.937µs] or [-13.946%; -13.927%]

scenario:profile_serialize_compressed_pprof_timestamped_x1000

  • 🟩 execution_time [-76.102µs; -75.086µs] or [-7.704%; -7.601%]

scenario:profiles_dictionary/profile_string_inserts/threads/1

  • 🟥 execution_time [+16.333µs; +20.214µs] or [+5.393%; +6.674%]
  • 🟥 throughput [-213219.586op/s; -171701.825op/s] or [-6.306%; -5.078%]

scenario:vec_map/as_deduped_map/already_deduped/8

  • 🟥 execution_time [+0.828ns; +0.845ns] or [+5.574%; +5.690%]

scenario:vec_map/get_hit/128

  • 🟩 execution_time [-2.855µs; -2.847µs] or [-17.280%; -17.233%]
  • 🟩 throughput [+1613496.861op/s; +1618151.197op/s] or [+20.825%; +20.885%]

scenario:vec_map/get_hit/16

  • 🟩 execution_time [-49.234ns; -49.057ns] or [-19.704%; -19.634%]
  • 🟩 throughput [+15652288.940op/s; +15705347.026op/s] or [+24.443%; +24.526%]

scenario:vec_map/get_hit/64

  • 🟩 execution_time [-635.542ns; -631.602ns] or [-14.643%; -14.553%]
  • 🟩 throughput [+2512598.786op/s; +2528705.827op/s] or [+17.039%; +17.148%]

scenario:vec_map/get_hit/8

  • 🟩 execution_time [-12.465ns; -12.423ns] or [-18.773%; -18.710%]
  • 🟩 throughput [+27736337.821op/s; +27839290.632op/s] or [+23.021%; +23.107%]

scenario:vec_map/iter/128

  • 🟩 execution_time [-8.525ns; -8.419ns] or [-7.582%; -7.488%]
  • 🟩 throughput [+92215413.109op/s; +93309495.415op/s] or [+8.100%; +8.196%]

scenario:vec_map/iter/16

  • 🟩 execution_time [-0.602ns; -0.594ns] or [-4.403%; -4.348%]
  • 🟩 throughput [+53219461.797op/s; +53913942.607op/s] or [+4.547%; +4.606%]

scenario:vec_map/iter/8

  • 🟩 execution_time [-0.574ns; -0.568ns] or [-7.933%; -7.844%]
  • 🟩 throughput [+94100312.579op/s; +95258589.928op/s] or [+8.513%; +8.618%]

Benchmark execution time: 2026-07-31 18:37:00

Comparing candidate commit 66e5b36 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit 7b8cb2a in branch main.

Found 17 performance improvements and 4 performance regressions! Performance is the same for 121 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:alloc_free/system/4096

  • 🟩 execution_time [-9.680ns; -9.487ns] or [-10.389%; -10.181%]

scenario:credit_card/is_card_number/ 3782-8224-6310-005

  • 🟩 execution_time [-4.959µs; -4.763µs] or [-6.197%; -5.952%]
  • 🟩 throughput [+792063.346op/s; +826000.123op/s] or [+6.338%; +6.610%]

scenario:credit_card/is_card_number/ 378282246310005

  • 🟩 execution_time [-5.784µs; -5.716µs] or [-7.862%; -7.770%]
  • 🟩 throughput [+1145961.599op/s; +1158712.290op/s] or [+8.431%; +8.524%]

scenario:credit_card/is_card_number/378282246310005

  • 🟩 execution_time [-5.686µs; -5.609µs] or [-8.097%; -7.987%]
  • 🟩 throughput [+1237089.235op/s; +1252876.265op/s] or [+8.688%; +8.799%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟩 execution_time [-7.028µs; -6.963µs] or [-13.444%; -13.319%]
  • 🟩 throughput [+2939979.740op/s; +2971678.934op/s] or [+15.369%; +15.535%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟩 execution_time [-5.293µs; -5.240µs] or [-9.072%; -8.982%]
  • 🟩 throughput [+1692680.687op/s; +1708905.411op/s] or [+9.875%; +9.970%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟩 execution_time [-5.517µs; -5.459µs] or [-9.969%; -9.864%]
  • 🟩 throughput [+1979065.794op/s; +1998690.299op/s] or [+10.953%; +11.061%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟩 execution_time [-7.013µs; -6.954µs] or [-13.415%; -13.304%]
  • 🟩 throughput [+2936216.254op/s; +2964288.943op/s] or [+15.349%; +15.495%]

scenario:glob_matcher/ascii_exact_miss/wall_time

  • 🟥 execution_time [+1.568ns; +1.625ns] or [+11.709%; +12.134%]

scenario:glob_matcher/ascii_wildcard_question_match/wall_time

  • 🟩 execution_time [-22.407ns; -22.384ns] or [-37.107%; -37.069%]

scenario:glob_matcher/ascii_wildcard_star_match/wall_time

  • 🟩 execution_time [-25.017ns; -24.945ns] or [-40.018%; -39.904%]

scenario:glob_matcher/unicode_pattern_ascii_subject/wall_time

  • 🟥 execution_time [+5.263ns; +5.306ns] or [+5.752%; +5.799%]

scenario:trace_buffer/4_senders/no_delay

  • 🟥 execution_time [+165.332µs; +192.301µs] or [+7.204%; +8.379%]
  • 🟥 throughput [-123606.454op/s; -105687.921op/s] or [-7.870%; -6.729%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@gyuheon0h
gyuheon0h marked this pull request as draft July 27, 2026 21:07
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 978bf00 to 67df7e6 Compare July 28, 2026 02:36
@scottgerring
scottgerring self-requested a review July 28, 2026 05:53
@scottgerring

scottgerring commented Jul 28, 2026

Copy link
Copy Markdown
Member

Hey @gyuheon0h cool - this is a good idea! We don't want to end up maintaining N variants of this sort of thing.
Happy to review this but it will have to wait til next week; i'll regress it against all my stuff just to be extra sure before we merge and this week is hectic. For the new hashing modes, you'll want to make sure you test against real binaries linked in this fashion.

@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from ea56fb3 to ced5999 Compare July 28, 2026 13:40
@gyuheon0h
gyuheon0h marked this pull request as ready for review July 28, 2026 14:25

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ced5999cd0

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread libdd-gotter/src/elf.rs
Comment thread libdd-got-hook/src/lib.rs Outdated
Comment thread libdd-gotter/src/elf.rs
Comment thread libdd-gotter/Cargo.toml
Comment thread libdd-profiling-heap-gotter/Cargo.toml Outdated
Comment thread libdd-got-hook/Cargo.toml Outdated
@scottgerring

Copy link
Copy Markdown
Member

Nice - I wanted to do this! Will review first thing Monday 💪 Please don't merge beforehand as I'd like to double check all the allocation profiling stuff that rests on it.

@github-actions github-actions Bot removed the ci-build label Jul 29, 2026
@gyuheon0h

Copy link
Copy Markdown
Contributor Author

@yannham @scottgerring Ill just stack another PR on top of this with the new changes, so that this PR strictly only focuses on the initial "no new feature" refactor 👍

@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch 6 times, most recently from 560d0a6 to 45c074d Compare July 29, 2026 19:22
@gyuheon0h
gyuheon0h marked this pull request as ready for review July 29, 2026 19:47
Move the ELF parsing, dl_iterate_phdr iteration, PageProtGuard,
gnu_hash_symbol_count, gnu_hash_lookup, lookup_symbol, and related
utilities out of libdd-profiling-heap-gotter into a new libdd-got-hook
crate.

libdd-profiling-heap-gotter now depends on libdd-got-hook and keeps
only the SymbolOverrides multi-symbol registry and per-library
dedup/rescan logic. This is a pure code move — no behavioral changes.
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 45c074d to 11a3920 Compare July 30, 2026 16:39
@gyuheon0h
gyuheon0h requested a review from yannham July 30, 2026 19:11
Comment thread libdd-got-hook/Cargo.toml Outdated

@scottgerring scottgerring left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @gyuheon0h , thanks for taking the time to split this out and make it re-usable! 🙌
Apart from a handful of nits, I think the two things to agree on are the name of the crate (some suggestions inline) and the shape of the API introduced around DynamicInfo

Comment thread libdd-got-hook/Cargo.toml Outdated
Comment thread libdd-gotter/Cargo.toml
Comment thread libdd-gotter/src/elf.rs
/// currently-loaded ELF object.
pub unsafe fn gnu_hash_lookup(info: &DynamicInfo, name: &[u8]) -> Option<Elf64_Sym> {
let hashtab = info.gnu_hash;
if hashtab.is_null() || info.gnu_hash_words < 4 {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra defensive check welcome!

Comment thread libdd-profiling-heap-gotter/src/elf.rs Outdated
Comment thread libdd-profiling-heap-gotter/src/elf.rs Outdated
Comment thread libdd-got-hook/src/elf.rs Outdated
}

/// Access to REL relocations (pointer, count).
pub fn rels(&self) -> (*const Elf64_Rel, usize) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure the accessors here are adding much apart from indirection; this is just pushing the unsafe outwards.

I think something like this would be better as it adapts to a safe API and unburdens the caller, but I am also interested in what @yannham thinks:

pub unsafe fn rels(&self) -> Option<&[Elf64_Rel]>

.. basically if we're going to change this in the mechanical refactoring bit, we may as well deal with the null check and slice construction in the API itself.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree a slice API would be nice. I guess we can even make it safe if the ELF ABI guarantees that a well-formed Elf file will have an array-like layout for self.rels (and check for nulls here).

Comment thread libdd-gotter/src/elf.rs
Comment thread libdd-got-hook/src/elf.rs Outdated
Comment thread libdd-gotter/src/elf.rs
Comment thread libdd-gotter/src/elf.rs
@gyuheon0h
gyuheon0h requested a review from scottgerring July 31, 2026 17:49
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from aea0f42 to 66e5b36 Compare July 31, 2026 17:50
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 66e5b36 to 31e53ca Compare July 31, 2026 19:06
Comment thread libdd-gotter/src/elf.rs
//!
//! Scope:
//! * 64-bit Linux ELF only (`Elf64_*`).
//! * GNU hash tables only (`DT_GNU_HASH`). `DT_HASH` is not parsed; objects without a GNU hash

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have a way of tracking metrics on how often this happens?

Comment thread libdd-gotter/src/elf.rs
};

// ELF dynamic-section tags. The `libc` crate doesn't export these
// (they're processor-independent ELF spec constants). Values from `<elf.h>`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any sort of check that they stay in sync?

Comment thread libdd-gotter/README.md

## What it does

When a shared library calls an external function like `malloc`, it jumps through a pointer in its **Global Offset Table** -- a writable table that the dynamic linker fills at load time. This crate walks every loaded ELF object via `dl_iterate_phdr`, parses its `PT_DYNAMIC` segment, and rewrites GOT entries so calls are redirected to a hook function. The original function address is resolved and returned so the hook can forward to it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there good documentation on how ELF / GOT works that we can link here?

@scottgerring scottgerring Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ancient dark arts passed down from engineer to engineer 😆 😱
I found an article in phrack which is probably not corporate-appropriate but is pretty great. @nsavoire i'm not sure if you've ever seen anything good ?

Comment thread libdd-gotter/README.md

static ORIG_FN: AtomicUsize = AtomicUsize::new(0);

unsafe extern "C" fn my_hook(/* same signature as target */) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a best practice for ensuring this remains in sync / checking this at runtime?

Comment thread libdd-gotter/README.md
unsafe {
hook_symbol(c"__assert_fail", my_hook as *const () as usize, &mut orig_addr);
}
ORIG_FN.store(orig_addr, Ordering::Release);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If Release is required, document why

Comment thread libdd-gotter/src/elf.rs
if self.relas.is_null() || self.relas_count == 0 {
&[]
} else {
unsafe { core::slice::from_raw_parts(self.relas, self.relas_count) }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

safety comment

Comment thread libdd-gotter/src/elf.rs
if self.jmprels.is_null() || self.jmprels_count == 0 {
&[]
} else {
unsafe { core::slice::from_raw_parts(self.jmprels, self.jmprels_count) }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

safety comment

Comment thread libdd-gotter/src/elf.rs
}

let nbuckets = *hashtab;
let symbias = *hashtab.add(1);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where are these offsets documented

Comment thread libdd-gotter/src/elf.rs
pub fn new() -> Self {
// sysconf can return -1 on error; fall back to a conservative
// 4 KiB default if the query fails.
let raw = unsafe { sysconf(_SC_PAGESIZE) };

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

safety comment

Comment thread libdd-gotter/src/elf.rs
/// Used to remember each GOT page's original protection so we can restore
/// it after patching, rather than leaving Full-RELRO pages read-write for
/// the lifetime of the process.
pub fn read_proc_maps() -> Vec<MapEntry> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are there any tests for this?

@scottgerring scottgerring left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for addressing comments. Suggest addressing continued feedback on "how we can make this better" in the stacked PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants