AES: Add function pointer trampoline to avoid delocator issue (#2294)

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 <[email protected]>

Author: hanno-becker

crypto/fipsmodule/aes/mode_wrappers.c

@@ -54,21 +54,47 @@
 #include "../modes/internal.h"
 #include "../cipher/internal.h"
 
+// The following wrappers ensure that the delocator can handle the
+// function pointer calculation in AES_ctr128_encrypt. Without it,
+// on AArch64 there is risk of the calculations requiring a PC-relative
+// offset outside of the range (-1MB,1MB) addressable using `ADR`.
+static inline void aes_hw_ctr32_encrypt_blocks_wrapper(const uint8_t *in,
+						       uint8_t *out, size_t len,
+						       const AES_KEY *key,
+						       const uint8_t ivec[16])
+{
+    aes_hw_ctr32_encrypt_blocks(in, out, len, key, ivec);
+}
+
+#if defined(VPAES_CTR32)
+static inline void vpaes_ctr32_encrypt_blocks_wrapper(const uint8_t *in,
+                                                      uint8_t *out, size_t len,
+                                                      const AES_KEY *key,
+                                                      const uint8_t ivec[16]) {
+  vpaes_ctr32_encrypt_blocks(in, out, len, key, ivec);
+}
+#else // VPAES_CTR32
+static inline void vpaes_encrypt_wrapper(const uint8_t *in, uint8_t *out,
+                                         const AES_KEY *key) {
+  vpaes_encrypt(in, out, key);
+}
+#endif // !VPAES_CTR32
+
 void AES_ctr128_encrypt(const uint8_t *in, uint8_t *out, size_t len,
                         const AES_KEY *key, uint8_t ivec[AES_BLOCK_SIZE],
                         uint8_t ecount_buf[AES_BLOCK_SIZE], unsigned int *num) {
   if (hwaes_capable()) {
     CRYPTO_ctr128_encrypt_ctr32(in, out, len, key, ivec, ecount_buf, num,
-                                aes_hw_ctr32_encrypt_blocks);
+                                aes_hw_ctr32_encrypt_blocks_wrapper);
   } else if (vpaes_capable()) {
 #if defined(VPAES_CTR32)
     // TODO(davidben): On ARM, where |BSAES| is additionally defined, this could
     // use |vpaes_ctr32_encrypt_blocks_with_bsaes|.
     CRYPTO_ctr128_encrypt_ctr32(in, out, len, key, ivec, ecount_buf, num,
-                                vpaes_ctr32_encrypt_blocks);
+                                vpaes_ctr32_encrypt_blocks_wrapper);
 #else
     CRYPTO_ctr128_encrypt(in, out, len, key, ivec, ecount_buf, num,
-                          vpaes_encrypt);
+                          vpaes_encrypt_wrapper);
 #endif
   } else {
     CRYPTO_ctr128_encrypt_ctr32(in, out, len, key, ivec, ecount_buf, num,