On 6 February 2018 at 18:57, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 6 February 2018 at 18:56, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> On 6 February 2018 at 18:45, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> On 22 January 2018 at 17:26, Ard Biesheuvel <ard.biesheu...@linaro.org> >>> wrote: >>>> This implements emulation of the new SHA-512 instructions that have >>>> been added as an optional extensions to the ARMv8 Crypto Extensions >>>> in ARM v8.2. >>>> >>>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> >>> >>> >>>> +void HELPER(crypto_sha512h)(void *vd, void *vn, void *vm) >>>> +{ >>>> + uint64_t *rd = vd; >>>> + uint64_t *rn = vn; >>>> + uint64_t *rm = vm; >>>> + >>>> + rd[1] += S1_512(rm[1]) + cho512(rm[1], rn[0], rn[1]); >>>> + rd[0] += S1_512(rd[1] + rm[0]) + cho512(rd[1] + rm[0], rm[1], rn[0]); >>> >>> This gives the wrong answer if the destination register >>> happens to be the same as one of the inputs, because the >>> assignment to rd[1] will overwrite the input before the >>> calculation of rd[0] uses it. >>> >> >> It is supposed to use the new value of rd[1], so this is expected. >> > > Ah hold on, I hit send too quickly, apologies. > > Yes, if rd == rm, then it will assume the wrong value. I missed this > when doing the rewrite to use the new interface.
OK. It sounds like the fix is more complicated than I thought it was, though, so I'll leave this up to you. My tests show that these insns seem OK: SM3PARTW1, SM3PARTW2, SM3SS1, SM3TT1A, SM3TT1B, SM3TT2A, SM3TT2B EOR3, BCAX, XAR SHA512SU1 These ones fail: SHA512H, SHA512H2, SHA512SU0 SM4EKEY, SM4E You also forgot to enable the SM4 CPU feature in the 'any' CPU and set it in the guest elf hwcaps. thanks -- PMM