## Summary of changes

- Revert "Revert 'Reapply "Revert Load the tracer/profiler after
guardrails checks" (#6959)' (#6986)" #7051
- Avoid calling `dlclose` on glibc 2.34-2.36

## Reason for change

We want to make sure we only load the tracer/profiler libraries _after_
we have run guardrails checks. However, repeated attempts to do this
were causing crashes in our smoke tests on Fedora 35, on arm64 only.
After an (extensive) investigation, we finally tracked this down to a
bug in glibc itself. The full explanation is given below, but the upshot
is that calling `dlclose` on this buggy glibc version can cause crashes
at some later point.

## Implementation details

- Includes the "original" implementation that moves the tracer/profiler
after guardrails checks
- Before calling `dlclose`, check to see if we're on a buggy version of
glibc
- This is complicated by the fact we run the _same_ binary on glibc and
musl, so we have to make the glibc call _dynamically_, instead of
linking directly against the `gnu_get_libc_version` method.
- We avoid trying to load libc if we detect that we're on Alpine by
checking for `/etc/alpine-release`. This is slightly annoying, but
required in the native loader code.
- If we _do_ manage to call the glibc version, we check against the
blocklist. If the version is on it, we avoid ever calling dlclose.

## Test coverage

We have run repeated tests against the previously crashing tests, and
this has resolved the issue. Nevertheless, our recommendation for
customers should definitely be to upgrade to a stable version of glibc
wherever possible

## Other details

Overview of the bug: 
In certain versions of glibc, there is a TLS-reuse bug that can cause
crashes when unloading shared libraries. The bug was introduced in 2.34,
fixed in 2.36 on x86-64, and fixed in 2.37 on aarch64.
See [the bug
here](https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3921c5b40f293c57cb326f58713c924b0662ef59)
or [the explanation of the bug on
Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=2251557) (which is
where we saw the crashing issue).

glibc 2.34 shipped with a regression: after a `dlclose()` of a library
that carried dynamic-TLS, the loader could reuse the same "module-ID"
for a different library _without_ first clearing the associated DTV
(Dynamic Thread Vector) entry. The next time any code accessed that TLS
slot it could read or write an unmapped address, which cases a
`SIGSEGV`.

This manifested as a crash in the WAF when we called
`ddwaf_context_info` on arm64. It explicitly happens on arm64 when we
unload the continuous profiler shortly after loading it (which is normal
because it's not supported).

It manifests in this scenario because `ddwaf_context_init` starts like
this:

```assembly
+128  bl   __tls_get_addr     ; ask glibc for the TLS slot for libddwaf
+136  mrs  x11, TPIDR_EL0     ; TLS base for this thread
+140  ldrb w9, [x11, x0]      ; <–– boom if x0 points to a stale DTV entry
```

When we unload the continuous profiler and call `dlcose`, it causes the
glibc loader to hand out a recycled module-ID to `libddwaf`. When
`ddwaf_context_init` tries to access TLS in the `ldrb` instruction, `x11
+ x0` is outside every mapped version, and so it crashes.

Note that although calling `dlclose` with the continuous profiler _may_
trigger the issue (the actual crash is flaky depending on load/unload
timing and address layout), unloading _any_ library that is is built
with `__thread`/`thread_local` data could trigger the crash. To minimize
the risk of hitting this issue, we avoid calling `dlclose` entirely on
the flaky glibc versions

For more details [see
doc](https://docs.google.com/document/d/1aptwmprnd83VTZMKxrrTqmBF6eOayjCL36kj9LujCE8/edit?tab=t.0#heading=h.nytiofltvdb5)

Affected distros: 

| Distribution      | Version / Release             | glibc Version |
| ----------------- | ----------------------------- | ------------- |
| Fedora            | 35                            | 2.34          |
| Fedora            | 37                            | 2.36          |
| Ubuntu            | 21.10 ("Impish Indri")        | 2.34          |
| Ubuntu            | 22.04 LTS ("Jammy Jellyfish") | 2.35          |
| Debian            | 12 ("Bookworm")               | 2.36          |
| RHEL              | 9                             | 2.34          |
| CentOS            | 9                             | 2.34          |
| Amazon Linux 2023 | default                       | 2.34          |

## Summary of changes

- Don't try to load the profiler on Linux arm64 at all
- Cherry pick #7153 to see if it resolves the issues

## Reason for change

#7153 ran into what we think is glibc `dlclose` issue (i.e. #7125).
Given the profiler always bails out on arm64 as it's not yet supported,
this is the easiest way to ensure that we don't load (and therefore,
more importantly, we don't _unload_ the profiler on arm64).

## Implementation details

Comment out the profiler from the loader.conf for arm64. That ensures we
don't _try_ to load it on arm64, while making it easy to reenable for
testing etc.

## Test coverage

Cherry picked the #7153 smoke tests, to confirm it resolves the issues

## Other details

Supersedes #7153 given that it enables the tests to verify the fix

---------

Co-authored-by: Flavien Darche <11708575+e-n-0@users.noreply.github.com>

## Summary of changes

- Don't try to load the profiler on Linux arm64 at all
- Cherry pick #7153 to see if it resolves the issues

## Reason for change

#7153 ran into what we think is glibc `dlclose` issue (i.e. #7125).
Given the profiler always bails out on arm64 as it's not yet supported,
this is the easiest way to ensure that we don't load (and therefore,
more importantly, we don't _unload_ the profiler on arm64).

## Implementation details

Comment out the profiler from the loader.conf for arm64. That ensures we
don't _try_ to load it on arm64, while making it easy to reenable for
testing etc.

## Test coverage

Cherry picked the #7153 smoke tests, to confirm it resolves the issues

## Other details

Supersedes #7153 given that it enables the tests to verify the fix

---------

Co-authored-by: Flavien Darche <11708575+e-n-0@users.noreply.github.com>

## Summary of changes

- Revert "Revert 'Reapply "Revert Load the tracer/profiler after
guardrails checks" (#6959)' (#6986)" #7051
- Avoid calling `dlclose` on glibc 2.34-2.36

## Reason for change

We want to make sure we only load the tracer/profiler libraries _after_
we have run guardrails checks. However, repeated attempts to do this
were causing crashes in our smoke tests on Fedora 35, on arm64 only.
After an (extensive) investigation, we finally tracked this down to a
bug in glibc itself. The full explanation is given below, but the upshot
is that calling `dlclose` on this buggy glibc version can cause crashes
at some later point.

## Implementation details

- Includes the "original" implementation that moves the tracer/profiler
after guardrails checks
- Before calling `dlclose`, check to see if we're on a buggy version of
glibc
- This is complicated by the fact we run the _same_ binary on glibc and
musl, so we have to make the glibc call _dynamically_, instead of
linking directly against the `gnu_get_libc_version` method.
- We avoid trying to load libc if we detect that we're on Alpine by
checking for `/etc/alpine-release`. This is slightly annoying, but
required in the native loader code.
- If we _do_ manage to call the glibc version, we check against the
blocklist. If the version is on it, we avoid ever calling dlclose.

## Test coverage

We have run repeated tests against the previously crashing tests, and
this has resolved the issue. Nevertheless, our recommendation for
customers should definitely be to upgrade to a stable version of glibc
wherever possible

## Other details

Overview of the bug: 
In certain versions of glibc, there is a TLS-reuse bug that can cause
crashes when unloading shared libraries. The bug was introduced in 2.34,
fixed in 2.36 on x86-64, and fixed in 2.37 on aarch64.
See [the bug
here](https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3921c5b40f293c57cb326f58713c924b0662ef59)
or [the explanation of the bug on
Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=2251557) (which is
where we saw the crashing issue).

glibc 2.34 shipped with a regression: after a `dlclose()` of a library
that carried dynamic-TLS, the loader could reuse the same "module-ID"
for a different library _without_ first clearing the associated DTV
(Dynamic Thread Vector) entry. The next time any code accessed that TLS
slot it could read or write an unmapped address, which cases a
`SIGSEGV`.

This manifested as a crash in the WAF when we called
`ddwaf_context_info` on arm64. It explicitly happens on arm64 when we
unload the continuous profiler shortly after loading it (which is normal
because it's not supported).

It manifests in this scenario because `ddwaf_context_init` starts like
this:

```assembly
+128  bl   __tls_get_addr     ; ask glibc for the TLS slot for libddwaf
+136  mrs  x11, TPIDR_EL0     ; TLS base for this thread
+140  ldrb w9, [x11, x0]      ; <–– boom if x0 points to a stale DTV entry
```

When we unload the continuous profiler and call `dlcose`, it causes the
glibc loader to hand out a recycled module-ID to `libddwaf`. When
`ddwaf_context_init` tries to access TLS in the `ldrb` instruction, `x11
+ x0` is outside every mapped version, and so it crashes.

Note that although calling `dlclose` with the continuous profiler _may_
trigger the issue (the actual crash is flaky depending on load/unload
timing and address layout), unloading _any_ library that is is built
with `__thread`/`thread_local` data could trigger the crash. To minimize
the risk of hitting this issue, we avoid calling `dlclose` entirely on
the flaky glibc versions

For more details [see
doc](https://docs.google.com/document/d/1aptwmprnd83VTZMKxrrTqmBF6eOayjCL36kj9LujCE8/edit?tab=t.0#heading=h.nytiofltvdb5)

Affected distros: 

| Distribution      | Version / Release             | glibc Version |
| ----------------- | ----------------------------- | ------------- |
| Fedora            | 35                            | 2.34          |
| Fedora            | 37                            | 2.36          |
| Ubuntu            | 21.10 ("Impish Indri")        | 2.34          |
| Ubuntu            | 22.04 LTS ("Jammy Jellyfish") | 2.35          |
| Debian            | 12 ("Bookworm")               | 2.36          |
| RHEL              | 9                             | 2.34          |
| CentOS            | 9                             | 2.34          |
| Amazon Linux 2023 | default                       | 2.34          |

## Summary of changes

- Don't try to load the profiler on Linux arm64 at all
- Cherry pick #7153 to see if it resolves the issues

## Reason for change

#7153 ran into what we think is glibc `dlclose` issue (i.e. #7125).
Given the profiler always bails out on arm64 as it's not yet supported,
this is the easiest way to ensure that we don't load (and therefore,
more importantly, we don't _unload_ the profiler on arm64).

## Implementation details

Comment out the profiler from the loader.conf for arm64. That ensures we
don't _try_ to load it on arm64, while making it easy to reenable for
testing etc.

## Test coverage

Cherry picked the #7153 smoke tests, to confirm it resolves the issues

## Other details

Supersedes #7153 given that it enables the tests to verify the fix

---------

Co-authored-by: Flavien Darche <11708575+e-n-0@users.noreply.github.com>