2.28: Fix AESNI selection

[lpy4105]

Description

Fix: #8168

This PR does a clean-up of the arch detection and implementation selection macros in include/mbedtls/aesni.h, similar to #7384. This would fix the issue when building with MSVC for ARM/ARM64 target if MBEDTLS_AESNI_C is not disabled.

PR checklist

• changelogNot required (Cleanup-rework build platoform)
• backport not required
• tests not required

[yanrayw]

LGTM, only two minor issues.

[lpy4105]

Please correct me if I was wrong, I think building ARM/ARM64 target using MSVC is not officially support, so here are two questions:

• I think this is an 'internal' change, but do we need a bugfix changelog entry?
• We don't need to provide relative tests on our CI, is that correct?

[tom-cosgrove-arm]

Just to confirm, (cross) building on X86_64 for ARM64 with default config, on 2.28 I get #error: This header is specific to X86 and X64 targets - that is fixed by this PR.

There is no such issue on development

[yanrayw]

LGTM

[tom-cosgrove-arm]

I've also confirmed that we get NI compiled in with intrinsics (and Padlock support, if enabled) when targeting (Linux) 32-bit (with -maes etc), NI compiled in with assembler when targeting Linux/x86_64, and NI via intrinsics when targeting Linux/x86_64 without assembler support (again, needing -maes etc) or Windows/amd64.

Note that if MBEDTLS_HAVE_ASM is turned off, and the user wants AES-NI, but doesn't include the full set of necessary command-line flags (e.g. -mpclmul -msse2 -maes), then the library will silently build without AES-NI

[tom-cosgrove-arm]

LGTM

[tom-cosgrove-arm]

Should #8168 not have been closed when this was merged?

[gilles-peskine-arm]

Should #8168 not have been closed when this was merged?

No, that only happens when a pull request is merged into the directory's default branch, which is development. LTS-only issues need to be closed manually.