Re: [PATCH 17/20] target/arm: Implement AESEMC

On Tue, 21 Jul 2026 at 19:52, Richard Henderson
<[email protected]> wrote:
>
> Signed-off-by: Richard Henderson <[email protected]>


> +void HELPER(crypto_aesemc)(void *vd, void *vn, void *vm, uint32_t desc)
> +{
> +    intptr_t opr_sz = simd_oprsz(desc);
> +    intptr_t idx = simd_data(desc);
> +    void *vm_idx = vm + idx * 16;
> +    intptr_t s = opr_sz - 16;
> +
> +    do {
> +        intptr_t base = ROUND_DOWN(s, 4 * 16);
> +        AESState rk = *(AESState *)(vm_idx + base);
> +        do {
> +            AESState *ad = (AESState *)(vd + s);
> +            AESState *st = (AESState *)(vn + s);
> +            AESState t;
> +
> +            /* Like above: Arm AK comes first; api AK comes last */
> +            if (HOST_BIG_ENDIAN) {
> +                t.d[0] = st->d[1] ^ rk.d[1];
> +                t.d[1] = st->d[0] ^ rk.d[0];
> +                aesenc_SB_SR_MC_AK(&t, &t, &aes_zero, false);
> +                ad->d[0] = t.d[1];
> +                ad->d[1] = t.d[0];
> +            } else {
> +                t.v = st->v ^ rk.v;
> +                aesenc_SB_SR_MC_AK(ad, &t, &aes_zero, false);

I did wonder why the Arm ARM describes this as "AddRoundKey(), ShiftRows(),
SubBytes(), and MixColumns()" whereas our AES functions do SB, SR, MC, AK,
but the answer seems to be that SB and SR can be done in either order
and you still get the same answer. (And the ordering of AK is as per the
comments here).

Reviewed-by: Peter Maydell <[email protected]>

thanks
-- PMM