On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative
offset in the range (-1MB, 1MB).

For the function pointer computations in aes/mode_wrappers.c,
this bounds condition is about to be violated by further code
additions to AWS-LC, as witnessed in AES-unrelated PRs.

This commit preventatively fixes the issue by adding function
pointer trampolines to crypto/fipsmodule/aes/mode_wrappers.c:
These are stub functions immediately branching into the desired
assembly routines, but close enough to the C code computing their
address to ensure that their addresses will be computable using
a PC-relative offset.

This fix is similar to aws#2165.

Mid/Long-term, it should be considered whether the delocator
can introduce the necessary indirections automatically.

Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>

On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative
offset in the range (-1MB, 1MB).

For the function pointer computations in aes/mode_wrappers.c,
this bounds condition is about to be violated by further code
additions to AWS-LC, as witnessed in AES-unrelated PRs.

This commit preventatively fixes the issue by adding function
pointer trampolines to crypto/fipsmodule/aes/mode_wrappers.c:
These are stub functions immediately branching into the desired
assembly routines, but close enough to the C code computing their
address to ensure that their addresses will be computable using
a PC-relative offset.

This fix is similar to aws#2165.

Mid/Long-term, it should be considered whether the delocator
can introduce the necessary indirections automatically.

Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>

On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative
offset in the range (-1MB, 1MB).

For the function pointer computations in aes/mode_wrappers.c,
this bounds condition is about to be violated by further code
additions to AWS-LC, as witnessed in AES-unrelated PRs.

This commit preventatively fixes the issue by adding function
pointer trampolines to crypto/fipsmodule/aes/mode_wrappers.c:
These are stub functions immediately branching into the desired
assembly routines, but close enough to the C code computing their
address to ensure that their addresses will be computable using
a PC-relative offset.

This fix is similar to aws#2165.

Mid/Long-term, it should be considered whether the delocator
can introduce the necessary indirections automatically.

Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>

On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative
offset in the range (-1MB, 1MB).

For the function pointer computations in aes/mode_wrappers.c,
this bounds condition is about to be violated by further code
additions to AWS-LC, as witnessed in AES-unrelated PRs.

This commit preventatively fixes the issue by adding function
pointer trampolines to crypto/fipsmodule/aes/mode_wrappers.c:
These are stub functions immediately branching into the desired
assembly routines, but close enough to the C code computing their
address to ensure that their addresses will be computable using
a PC-relative offset.

This fix is similar to aws#2165.

Mid/Long-term, it should be considered whether the delocator
can introduce the necessary indirections automatically.

Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>

On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative
offset in the range (-1MB, 1MB).

For the function pointer computations in aes/mode_wrappers.c,
this bounds condition is about to be violated by further code
additions to AWS-LC, as witnessed in AES-unrelated PRs.

This commit preventatively fixes the issue by adding function
pointer trampolines to crypto/fipsmodule/aes/mode_wrappers.c:
These are stub functions immediately branching into the desired
assembly routines, but close enough to the C code computing their
address to ensure that their addresses will be computable using
a PC-relative offset.

This fix is similar to aws#2165.

Mid/Long-term, it should be considered whether the delocator
can introduce the necessary indirections automatically.

Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

--------

On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative offset
in the range (-1MB, 1MB).

For the function pointer computations in aes/mode_wrappers.c, this
bounds condition is about to be violated by further code additions to
AWS-LC, as witnessed in AES-unrelated PRs (specifically #2176).

This commit preventatively fixes the issue by adding function pointer
trampolines to crypto/fipsmodule/aes/mode_wrappers.c: These are stub
functions immediately branching into the desired assembly routines, but
close enough to the C code computing their address to ensure that their
addresses will be computable using a PC-relative offset.

This fix is similar to #2165.

Mid/Long-term, it should be considered whether the delocator can
introduce the necessary indirections automatically.

Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>

…#2920)

### Service Indicator: Add error call trampoline to avoid delocator
issue

### Problem

On AArch64, the delocator can patch up PC-relative addressing only if
the references can be computed with a PC-relative offset in the range
(-1MB, 1MB).

For the `OPENSSL_PUT_ERROR` macro calls in
`crypto/fipsmodule/service_indicator/service_indicator.c`, the
`__FILE__` string literal references were exceeding the ARM64 ADR
instruction's ±1MB range limit as the FIPS module grew larger. This
manifested as build failures in ARM64 FIPS builds:

```
error: fixup value out of range
 adr x3, .L.str.192
 ^
```

The error originated from string literals being placed too far from
their usage sites (e.g., string at line ~365493, first use at line ~2597
in bcm-delocated.S).

### Solution

This commit fixes the issue by adding a non-inlined trampoline function
for error calls:

```c
#if defined(_MSC_VER)
__declspec(noinline)
#else
__attribute__((noinline))
#endif
static void put_set_thread_local_error(void) {
  OPENSSL_PUT_ERROR(CRYPTO, ERR_R_INTERNAL_ERROR);
}
```

This ensures the `__FILE__` string literal stays close to its usage site
and can be addressed using a PC-relative offset within the allowed
range.

### Key Distinction from Function Pointer Trampolines

This fix differs from previous function pointer trampolines (e.g.,
#2165), which wrapped assembly functions and used branch instructions to
call them. Here, the pointer is not to a function but to a string
literal (`__FILE__` from error macros), so instead we wrap the function
that uses the pointer to keep the string reference close to its usage.
The `noinline` directive is critical - without it, the compiler will
inline the function, placing the `__FILE__` reference back at the
original call sites and recreating the distance problem.


By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

Co-authored-by: Justin W Smith <103147162+justsmth@users.noreply.github.com>

…2919)

### Delocate AES, GCM, and cipher wrapper functions

On AArch64, the delocator can patch up the computation of function
pointers only if the pointers can be computed with a PC-relative offset
in the range (-1MB, 1MB).

For the function pointer computations in
`crypto/fipsmodule/aes/mode_wrappers.c`,
`crypto/fipsmodule/cipher/e_aes.c`, and `crypto/fipsmodule/modes/gcm.c`,
this bounds condition is about to be violated by further code additions
to AWS-LC, as witnessed in AES-unrelated PRs.

This commit preventatively fixes the issue by adding function pointer
trampolines to these files: These are stub functions immediately
branching into the desired assembly routines, but close enough to the C
code computing their address to ensure that their addresses will be
computable using a PC-relative offset.

This fix is similar to previous delocator fixes addressing the same
AArch64 PC-relative offset limitation, see
#2165,
#2294 for examples.

### AWS-LC-Verification

As there are SAW proofs for AES GCM, these changes affect the proofs
([formal-verification / fv-saw-x86_64-aes-gcm
(pull_request)](https://github.com/aws/aws-lc/actions/runs/20380843167/job/58570729683?pr=2919))
and require changes in aws-lc-verification to continue proof support --
this has been added in
awslabs/aws-lc-verification#180.

### Testing:
Stability of the fix was tested in
#2903 which added ~10,000 lines of
additional AVX2 backend.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.