On 12/31/14 19:08, Ard Biesheuvel wrote: > On 31 December 2014 at 17:37, Peter Maydell <peter.mayd...@linaro.org> wrote: >> On 31 December 2014 at 17:17, Peter Maydell <peter.mayd...@linaro.org> 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?
I'm not sure, but I seem to recall that Peter said that TCG held all the virtual registers in host-endianness. Laszlo
