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
