Implement requirement.json for injection

[TonyCTHsu]

Change log entry

None

What does this PR do?

Add requirement.json for injection.

Motivation:

Prevent injection when:

• we know system dependencies (libc, arch) aren't satisfied
• we know there's no point in injecting into a program (not useful, not effective, blocked by security policy)
• we know injecting into a program would be detrimental (breaking it due to incompatibility or security policy)

Additional Notes:

JIRA

• INPLAT-103

How to test the change?

Should be tested by CI in the added JSON test cases.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.73%. Comparing base (1ec3900) to head (357ec4c).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4019   +/-   ##
=======================================
  Coverage   97.73%   97.73%           
=======================================
  Files        1338     1338           
  Lines       80246    80245    -1     
  Branches     4014     4014           
=======================================
  Hits        78430    78430           
+ Misses       1816     1815    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-10-22 16:33:08

Comparing candidate commit c75462f in PR branch tonycthsu/denylist with baseline commit 38f6cc1 in branch master.

Found 0 performance improvements and 2 performance regressions! Performance is the same for 22 metrics, 2 unstable metrics.

scenario:profiler - hold / resume

• 🟥 throughput [-256863.487op/s; -255326.192op/s] or [-12.750%; -12.673%]

scenario:tracing - Propagation - Datadog

• 🟥 throughput [-2823.523op/s; -2715.521op/s] or [-8.504%; -8.179%]

[raphaelgavache]

2.28 is quite high for x86, do you know what symbol/dependency requires it?

running nm -D library_file | grep U will give you that answer

[lloeki]

The pipeline is using registry.ddbuild.io/images/mirror/buildpack-deps:buster as a base:

dd-trace-rb/.gitlab/Dockerfile-3.2.2

Line 4 in 1ec3900

FROM registry.ddbuild.io/images/mirror/buildpack-deps:buster

With which we get a glibc 2.28:

$ ldd --version
ldd (Debian GLIBC 2.28-10+deb10u2) 2.28

So gems with native extensions are built against that.

The version requirement comes from there.

This results in the following max version referenced (== min version required):

aarch64:

tmp/arm64/3.2.0/extensions/aarch64-linux/3.2.0-static/datadog-2.4.0/datadog_profiling_loader.3.2.2_aarch64-linux.so: GLIBC_2.17
tmp/arm64/3.2.0/extensions/aarch64-linux/3.2.0-static/datadog-2.4.0/libdatadog_api.3.2_aarch64-linux.so: GLIBC_2.17
tmp/arm64/3.2.0/extensions/aarch64-linux/3.2.0-static/ffi-1.16.3/ffi_c.so: GLIBC_2.27
tmp/arm64/3.2.0/extensions/aarch64-linux/3.2.0-static/msgpack-1.7.3/msgpack/msgpack.so: GLIBC_2.17
tmp/arm64/3.2.0/gems/datadog-2.4.0/lib/datadog_profiling_loader.3.2.2_aarch64-linux.so: GLIBC_2.17
tmp/arm64/3.2.0/gems/datadog-2.4.0/lib/libdatadog_api.3.2_aarch64-linux.so: GLIBC_2.17
tmp/arm64/3.2.0/gems/ffi-1.16.3/lib/ffi_c.so: GLIBC_2.27
tmp/arm64/3.2.0/gems/libdatadog-13.1.0.1.0-aarch64-linux/vendor/libdatadog-13.1.0/aarch64-linux-musl/libdatadog-aarch64-alpine-linux-musl/lib/libdatadog_profiling.so: GLIBC_2.0
tmp/arm64/3.2.0/gems/libdatadog-13.1.0.1.0-aarch64-linux/vendor/libdatadog-13.1.0/aarch64-linux/libdatadog-aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so: GLIBC_2.17
tmp/arm64/3.2.0/gems/libddwaf-1.14.0.0.0-aarch64-linux/vendor/libddwaf/libddwaf-1.14.0-linux-aarch64/lib/libddwaf.so: 
tmp/arm64/3.2.0/gems/msgpack-1.7.3/lib/msgpack/msgpack.so: GLIBC_2.17

x86_64:

tmp/x86_64/3.2.0/extensions/x86_64-linux/3.2.0-static/datadog-2.4.0/datadog_profiling_loader.3.2.2_x86_64-linux.so: GLIBC_2.2.5
tmp/x86_64/3.2.0/extensions/x86_64-linux/3.2.0-static/datadog-2.4.0/libdatadog_api.3.2_x86_64-linux.so: GLIBC_2.2.5
tmp/x86_64/3.2.0/extensions/x86_64-linux/3.2.0-static/ffi-1.16.3/ffi_c.so: GLIBC_2.27
tmp/x86_64/3.2.0/extensions/x86_64-linux/3.2.0-static/msgpack-1.7.3/msgpack/msgpack.so: GLIBC_2.14
tmp/x86_64/3.2.0/gems/datadog-2.4.0/lib/datadog_profiling_loader.3.2.2_x86_64-linux.so: GLIBC_2.2.5
tmp/x86_64/3.2.0/gems/datadog-2.4.0/lib/libdatadog_api.3.2_x86_64-linux.so: GLIBC_2.2.5
tmp/x86_64/3.2.0/gems/ffi-1.16.3/lib/ffi_c.so: GLIBC_2.27
tmp/x86_64/3.2.0/gems/libdatadog-13.1.0.1.0-x86_64-linux/vendor/libdatadog-13.1.0/x86_64-linux-musl/libdatadog-x86_64-alpine-linux-musl/lib/libdatadog_profiling.so: 
tmp/x86_64/3.2.0/gems/libdatadog-13.1.0.1.0-x86_64-linux/vendor/libdatadog-13.1.0/x86_64-linux/libdatadog-x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so: GLIBC_2.16
tmp/x86_64/3.2.0/gems/libddwaf-1.14.0.0.0-x86_64-linux/vendor/libddwaf/libddwaf-1.14.0-linux-x86_64/lib/libddwaf.so: 
tmp/x86_64/3.2.0/gems/msgpack-1.7.3/lib/msgpack/msgpack.so: GLIBC_2.14

ffi is the one using GLIBC_2.27. So we can lower it to 2.27 but until we move to building against a lower glibc (which comes with its own set of issues) we're stuck with that. FYI using manylinux is under consideration.

[raphaelgavache]

if it helps you can pick agent build images or the ones used by the injector:

• centos7 for amd
• for arm

Given that you download the source codes, won't building ffi on those machines improve your coverage? Or are there specific recent symbols that are required

[lloeki]

I think memfd_create needs glibc 2.27.

It looks like libffi has fallback mechanisms if it is absent (see Memory Usage), but it is an important security feature.

Note: we're looking into removing the ffi dependency entirely mid-term.

[lloeki]

Tests passed on this minimal one.

[lloeki]

• Rebased.
• Undrafted for review.
• Once tests pass we can merge this, with further improvements down the road, notably covering for INPLAT-103