## 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

- 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

- 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          |