Remove dead tail code from (non-SHA3) AES-GCM AArch64 kernel

[hanno-becker]

On AArch64 systems without support for EOR3, assembly kernels aes_gcm_enc_kernel and aes_gcm_dec_kernel from aesv8-gcm-armv8.pl are used for the bulk of AES-GCM processing. These kernels have dedicated tail code for handling inputs whose size is not a multiple of the block size (16 bytes).

However, the unique call-sites for aes_gcm_enc_kernel and aes_gcm_dec_kernel in gcm.c only invoke them with data of size a multiple of 16 bytes: See the masking here here and here. This renders the tail code in aesv8-gcm-armv8.pl dead.

Simply removing the truncation to 16-byte aligned data in gcm.c -- that is, attempting to let aes_gcm_{dec,enc}_kernel process the entire data -- leads to tests failing. It is not clear to me why that is, and in particular the tail code could be faulty. OpenSSL seems to behave similarly and call the AArch64 AES-GCM kernels for block-sized data only.

This PR removes the dead tail code from the non-SHA3 AES-GCM kernels aes_gcm_enc_kernel and aes_gcm_dec_kernel. In a first commit, the code is annotated to explain the effect of the tail code in case of block-aligned data. In the second commit, the tail code is removed.

It seems that a similar change can be made for the AES-GCM kernels leveraging SHA3 instructions, but is not attempted here. (The primary motivation for this change is to facilitate @pennyannn's verification work, which focuses on the non-SHA3 kernels).

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.20%. Comparing base (4368aaa) to head (1ed3d56).
Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1639      +/-   ##
==========================================
- Coverage   78.22%   78.20%   -0.02%     
==========================================
  Files         566      571       +5     
  Lines       95165    95458     +293     
  Branches    13661    13706      +45     
==========================================
+ Hits        74442    74657     +215     
- Misses      20127    20191      +64     
- Partials      596      610      +14     

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

[hanno-becker]

@torben-hansen Did I understand correctly that the CI failures are unrelated to this PR?

[hanno-becker]

Review note: Make sure to review commit 12ac5a2 separately as it provides some explanation of why the lines that are removed are indeed dispensable.

[dkostic]

not material for this change, but I'm really curious why are the tests failing when you try to process non-block aligned data with the removed code.

[nebeid]

Thanks, @hanno-becker, for this contribution. Just a nit comment.

[hanno-becker]

@dkostic not material for this change, but I'm really curious why are the tests failing when you try to process non-block aligned data with the removed code.

It turns out that the tail code isn't buggy, it just presents a different interface to AES: For non-block aligned data, the tail code pads the data with 0 in the last block and computes AES + GHASH. That's different from the incremental behaviour of functions like CRYPTO_gcm128_encrypt_ctr32: When those find tail data smaller than a block, they just stash it in the AES context, until (a) further data completes the block, or (b) the entire computation is concluded, forcing the padding + final GHASH.

Rewriting the tail code assembly to suit the incremental AES interface is doable but not trivial (the tail code computes (((t3*H) + t2)*H + t1)*H=t3 * H^3 + t2 * H^2 + t1*H, so if you instead want to compute ((t3*H) + t2)*H + t1, you have to change precomputed H-factors in earlier parts of the tail code, or switch to a simpler tail code which does not use H^2, H^3), so I'd suggest to revisit this alongside the integration of the clean and SLOTHY-optimized AES-GCM at a later stage.

[hanno-becker]

Tested on Graviton2 to replace unrelated CI failure:

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release .. && make -j8
./crypto/crypto_test
./ssl/ssl_test

All successful.