Re: [Qemu-devel] [PATCH] fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write()

[Ard Biesheuvel]

On 31 December 2014 at 17:37, Peter Maydell <address@hidden> wrote:
> On 31 December 2014 at 17:17, Peter Maydell <address@hidden> wrote:
>> One thing I did notice in the dmesg:
>>
>> [   35.798423] alg: hash: Test 1 failed for sha1-ce
>> [   35.799135] 00000000: d3 5b 9a 85 7f 18 48 21 97 5c 12 72 a8 96 62 88
>> [   35.799815] 00000010: c3 d2 e1 f0
>> [   35.807121] alg: hash: Test 1 failed for sha224-ce
>> [   35.807458] 00000000: 75 49 49 85 18 97 6f 0c a7 d3 c3 ee 54 5d b3 59
>> [   35.807910] 00000010: a0 97 b3 34 f8 9c ab c1 91 e1 24 9e
>> [   35.814059] alg: hash: Test 1 failed for sha256-ce
>> [   35.814450] 00000000: b9 cb b3 d4 f5 29 fa 2c 8f 9b 8e 67 e9 6d 24 9b
>> [   35.814897] 00000010: 83 da e8 b1 ba 32 6c bb 4e 53 77 76 fc 11 e4 aa
>> [   35.827619] alg: cipher: Test 1 failed on encryption for aes-ce
>> [   35.828042] 00000000: ba 4a ec ea df 05 7d 76 56 af 92 77 5d 00 e0 90
>>
>> ...does that happen on little endian TCG hosts too, or do we have
>> a bug in our encryption emulation?
>
> It doesn't happen on LE TCG hosts. Joy :-)
>

I will need to find out first if this is the kernel driver or the
emulation failing. I never tested the former on BE, as the models
don't support the crypto extensions (at least, not without a plugin
that I don't have access to) and the actual hardware boots via EFI
which is LE only, and with no 'ground truth' as a reference, it is
hard to be 100% certain both implementations are in spec, even if they
work in combination.

The SHA emulation code only operates on 32-bit quantities, and the
only memory access it does is populating the CRYPTO_STATE union using
float64_val(). Does anyone feel there is anything obviously wrong with
that?

-- 
Ard.