* [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support @ 2015-01-02 14:18 Ard Biesheuvel 2015-01-02 15:17 ` Laszlo Ersek 0 siblings, 1 reply; 8+ messages in thread From: Ard Biesheuvel @ 2015-01-02 14:18 UTC (permalink / raw) To: qemu-devel, peter.maydell; +Cc: lersek, Ard Biesheuvel The crypto emulation code in target-arm/crypto_helper.c never worked correctly on big endian hosts, due to the fact that it uses a union of array types to convert between the native VFP register size (64 bits) and the types used in the algorithms (bytes and 32 bit words) We cannot just swab between LE and BE when reading and writing the registers, as the SHA code performs word additions, so instead, add array accessors for the CRYPTO_STATE type whose LE and BE specific implementations ensure that the correct array elements are referenced. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- Only tested on a LE (amd64) host, as I don't have access to a BE host. target-arm/crypto_helper.c | 114 +++++++++++++++++++++++++-------------------- 1 file changed, 63 insertions(+), 51 deletions(-) diff --git a/target-arm/crypto_helper.c b/target-arm/crypto_helper.c index dd60d0b81a4c..1fe975d0f1e3 100644 --- a/target-arm/crypto_helper.c +++ b/target-arm/crypto_helper.c @@ -22,6 +22,14 @@ union CRYPTO_STATE { uint64_t l[2]; }; +#ifdef HOST_WORDS_BIGENDIAN +#define CR_ST_BYTE(state, i) (state.bytes[(15 - (i)) ^ 8]) +#define CR_ST_WORD(state, i) (state.words[(3 - (i)) ^ 2]) +#else +#define CR_ST_BYTE(state, i) (state.bytes[i]) +#define CR_ST_WORD(state, i) (state.words[i]) +#endif + void HELPER(crypto_aese)(CPUARMState *env, uint32_t rd, uint32_t rm, uint32_t decrypt) { @@ -46,7 +54,7 @@ void HELPER(crypto_aese)(CPUARMState *env, uint32_t rd, uint32_t rm, /* combine ShiftRows operation and sbox substitution */ for (i = 0; i < 16; i++) { - st.bytes[i] = sbox[decrypt][rk.bytes[shift[decrypt][i]]]; + CR_ST_BYTE(st, i) = sbox[decrypt][CR_ST_BYTE(rk, shift[decrypt][i])]; } env->vfp.regs[rd] = make_float64(st.l[0]); @@ -198,11 +206,11 @@ void HELPER(crypto_aesmc)(CPUARMState *env, uint32_t rd, uint32_t rm, assert(decrypt < 2); for (i = 0; i < 16; i += 4) { - st.words[i >> 2] = cpu_to_le32( - mc[decrypt][st.bytes[i]] ^ - rol32(mc[decrypt][st.bytes[i + 1]], 8) ^ - rol32(mc[decrypt][st.bytes[i + 2]], 16) ^ - rol32(mc[decrypt][st.bytes[i + 3]], 24)); + CR_ST_WORD(st, i >> 2) = + mc[decrypt][CR_ST_BYTE(st, i)] ^ + rol32(mc[decrypt][CR_ST_BYTE(st, i + 1)], 8) ^ + rol32(mc[decrypt][CR_ST_BYTE(st, i + 2)], 16) ^ + rol32(mc[decrypt][CR_ST_BYTE(st, i + 3)], 24); } env->vfp.regs[rd] = make_float64(st.l[0]); @@ -255,24 +263,25 @@ void HELPER(crypto_sha1_3reg)(CPUARMState *env, uint32_t rd, uint32_t rn, switch (op) { case 0: /* sha1c */ - t = cho(d.words[1], d.words[2], d.words[3]); + t = cho(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); break; case 1: /* sha1p */ - t = par(d.words[1], d.words[2], d.words[3]); + t = par(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); break; case 2: /* sha1m */ - t = maj(d.words[1], d.words[2], d.words[3]); + t = maj(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); break; default: g_assert_not_reached(); } - t += rol32(d.words[0], 5) + n.words[0] + m.words[i]; - - n.words[0] = d.words[3]; - d.words[3] = d.words[2]; - d.words[2] = ror32(d.words[1], 2); - d.words[1] = d.words[0]; - d.words[0] = t; + t += rol32(CR_ST_WORD(d, 0), 5) + CR_ST_WORD(n, 0) + + CR_ST_WORD(m, i); + + CR_ST_WORD(n, 0) = CR_ST_WORD(d, 3); + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); + CR_ST_WORD(d, 2) = ror32(CR_ST_WORD(d, 1), 2); + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); + CR_ST_WORD(d, 0) = t; } } env->vfp.regs[rd] = make_float64(d.l[0]); @@ -286,8 +295,8 @@ void HELPER(crypto_sha1h)(CPUARMState *env, uint32_t rd, uint32_t rm) float64_val(env->vfp.regs[rm + 1]) } }; - m.words[0] = ror32(m.words[0], 2); - m.words[1] = m.words[2] = m.words[3] = 0; + CR_ST_WORD(m, 0) = ror32(CR_ST_WORD(m, 0), 2); + CR_ST_WORD(m, 1) = CR_ST_WORD(m, 2) = CR_ST_WORD(m, 3) = 0; env->vfp.regs[rd] = make_float64(m.l[0]); env->vfp.regs[rd + 1] = make_float64(m.l[1]); @@ -304,10 +313,10 @@ void HELPER(crypto_sha1su1)(CPUARMState *env, uint32_t rd, uint32_t rm) float64_val(env->vfp.regs[rm + 1]) } }; - d.words[0] = rol32(d.words[0] ^ m.words[1], 1); - d.words[1] = rol32(d.words[1] ^ m.words[2], 1); - d.words[2] = rol32(d.words[2] ^ m.words[3], 1); - d.words[3] = rol32(d.words[3] ^ d.words[0], 1); + CR_ST_WORD(d, 0) = rol32(CR_ST_WORD(d, 0) ^ CR_ST_WORD(m, 1), 1); + CR_ST_WORD(d, 1) = rol32(CR_ST_WORD(d, 1) ^ CR_ST_WORD(m, 2), 1); + CR_ST_WORD(d, 2) = rol32(CR_ST_WORD(d, 2) ^ CR_ST_WORD(m, 3), 1); + CR_ST_WORD(d, 3) = rol32(CR_ST_WORD(d, 3) ^ CR_ST_WORD(d, 0), 1); env->vfp.regs[rd] = make_float64(d.l[0]); env->vfp.regs[rd + 1] = make_float64(d.l[1]); @@ -356,20 +365,22 @@ void HELPER(crypto_sha256h)(CPUARMState *env, uint32_t rd, uint32_t rn, int i; for (i = 0; i < 4; i++) { - uint32_t t = cho(n.words[0], n.words[1], n.words[2]) + n.words[3] - + S1(n.words[0]) + m.words[i]; - - n.words[3] = n.words[2]; - n.words[2] = n.words[1]; - n.words[1] = n.words[0]; - n.words[0] = d.words[3] + t; - - t += maj(d.words[0], d.words[1], d.words[2]) + S0(d.words[0]); - - d.words[3] = d.words[2]; - d.words[2] = d.words[1]; - d.words[1] = d.words[0]; - d.words[0] = t; + uint32_t t = cho(CR_ST_WORD(n, 0), CR_ST_WORD(n, 1), CR_ST_WORD(n, 2)) + + CR_ST_WORD(n, 3) + S1(CR_ST_WORD(n, 0)) + + CR_ST_WORD(m, i); + + CR_ST_WORD(n, 3) = CR_ST_WORD(n, 2); + CR_ST_WORD(n, 2) = CR_ST_WORD(n, 1); + CR_ST_WORD(n, 1) = CR_ST_WORD(n, 0); + CR_ST_WORD(n, 0) = CR_ST_WORD(d, 3) + t; + + t += maj(CR_ST_WORD(d, 0), CR_ST_WORD(d, 1), CR_ST_WORD(d, 2)) + + S0(CR_ST_WORD(d, 0)); + + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); + CR_ST_WORD(d, 2) = CR_ST_WORD(d, 1); + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); + CR_ST_WORD(d, 0) = t; } env->vfp.regs[rd] = make_float64(d.l[0]); @@ -394,13 +405,14 @@ void HELPER(crypto_sha256h2)(CPUARMState *env, uint32_t rd, uint32_t rn, int i; for (i = 0; i < 4; i++) { - uint32_t t = cho(d.words[0], d.words[1], d.words[2]) + d.words[3] - + S1(d.words[0]) + m.words[i]; - - d.words[3] = d.words[2]; - d.words[2] = d.words[1]; - d.words[1] = d.words[0]; - d.words[0] = n.words[3 - i] + t; + uint32_t t = cho(CR_ST_WORD(d, 0), CR_ST_WORD(d, 1), CR_ST_WORD(d, 2)) + + CR_ST_WORD(d, 3) + S1(CR_ST_WORD(d, 0)) + + CR_ST_WORD(m, i); + + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); + CR_ST_WORD(d, 2) = CR_ST_WORD(d, 1); + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); + CR_ST_WORD(d, 0) = CR_ST_WORD(n, 3 - i) + t; } env->vfp.regs[rd] = make_float64(d.l[0]); @@ -418,10 +430,10 @@ void HELPER(crypto_sha256su0)(CPUARMState *env, uint32_t rd, uint32_t rm) float64_val(env->vfp.regs[rm + 1]) } }; - d.words[0] += s0(d.words[1]); - d.words[1] += s0(d.words[2]); - d.words[2] += s0(d.words[3]); - d.words[3] += s0(m.words[0]); + CR_ST_WORD(d, 0) += s0(CR_ST_WORD(d, 1)); + CR_ST_WORD(d, 1) += s0(CR_ST_WORD(d, 2)); + CR_ST_WORD(d, 2) += s0(CR_ST_WORD(d, 3)); + CR_ST_WORD(d, 3) += s0(CR_ST_WORD(m, 0)); env->vfp.regs[rd] = make_float64(d.l[0]); env->vfp.regs[rd + 1] = make_float64(d.l[1]); @@ -443,10 +455,10 @@ void HELPER(crypto_sha256su1)(CPUARMState *env, uint32_t rd, uint32_t rn, float64_val(env->vfp.regs[rm + 1]) } }; - d.words[0] += s1(m.words[2]) + n.words[1]; - d.words[1] += s1(m.words[3]) + n.words[2]; - d.words[2] += s1(d.words[0]) + n.words[3]; - d.words[3] += s1(d.words[1]) + m.words[0]; + CR_ST_WORD(d, 0) += s1(CR_ST_WORD(m, 2)) + CR_ST_WORD(n, 1); + CR_ST_WORD(d, 1) += s1(CR_ST_WORD(m, 3)) + CR_ST_WORD(n, 2); + CR_ST_WORD(d, 2) += s1(CR_ST_WORD(d, 0)) + CR_ST_WORD(n, 3); + CR_ST_WORD(d, 3) += s1(CR_ST_WORD(d, 1)) + CR_ST_WORD(m, 0); env->vfp.regs[rd] = make_float64(d.l[0]); env->vfp.regs[rd + 1] = make_float64(d.l[1]); -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-02 14:18 [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support Ard Biesheuvel @ 2015-01-02 15:17 ` Laszlo Ersek 2015-01-02 17:36 ` Peter Maydell 2015-01-02 19:21 ` Ard Biesheuvel 0 siblings, 2 replies; 8+ messages in thread From: Laszlo Ersek @ 2015-01-02 15:17 UTC (permalink / raw) To: Ard Biesheuvel, qemu-devel, peter.maydell On 01/02/15 15:18, Ard Biesheuvel wrote: > The crypto emulation code in target-arm/crypto_helper.c never worked > correctly on big endian hosts, due to the fact that it uses a union > of array types to convert between the native VFP register size (64 > bits) and the types used in the algorithms (bytes and 32 bit words) > > We cannot just swab between LE and BE when reading and writing the > registers, as the SHA code performs word additions, so instead, add > array accessors for the CRYPTO_STATE type whose LE and BE specific > implementations ensure that the correct array elements are referenced. > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > > Only tested on a LE (amd64) host, as I don't have access to a BE host. > > target-arm/crypto_helper.c | 114 +++++++++++++++++++++++++-------------------- > 1 file changed, 63 insertions(+), 51 deletions(-) > > diff --git a/target-arm/crypto_helper.c b/target-arm/crypto_helper.c > index dd60d0b81a4c..1fe975d0f1e3 100644 > --- a/target-arm/crypto_helper.c > +++ b/target-arm/crypto_helper.c > @@ -22,6 +22,14 @@ union CRYPTO_STATE { > uint64_t l[2]; > }; > > +#ifdef HOST_WORDS_BIGENDIAN > +#define CR_ST_BYTE(state, i) (state.bytes[(15 - (i)) ^ 8]) Produces 7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9 which I think is consistent with what Peter wrote. > +#define CR_ST_WORD(state, i) (state.words[(3 - (i)) ^ 2]) Hm. The indices look good: 1, 0 3, 2 But, assuming you're on a big-endian host, perhaps you should byte swap the uint32_t too?... > (ie if you store 0x112233445566778899aabbccddeeff00 as a 64 bit write > to VFP register D0 then regs[0] will be > 0x112233445566778899aabbccddeeff00 regardless of host endianness. That > is, the least significant 8 bits of D0 will be (regs[0] & 0xff). (This > isn't the same number as if you do the union-type-punning thing with > union { uint64_t l; uint8_t b[8]; } and look at b[0].) Assume the guest writes value 0x112233445566778899aabbccddeeff00 (LE representation). * Assuming a little endian host, we get: [00 ff ee dd cc bb aa 99 88 77 66 55 44 33 22 11] (full 128-bit LE vector). This is grouped into units of four bytes for the words array: [00 ff ee dd] [cc bb aa 99] [88 77 66 55] [44 33 22 11] And the meaning of the individual uint32_t's is: 0xddeeff00 0x99aabbcc 0x55667788 0x11223344 Which are the building blocks for the crypto primitives. * Assuming a big endian host, you get the following byte array for the same store (if I understand Peter right -- two uint64_t values are encoded as host endian, but the ordering between those remains little endian): [99 aa bb cc dd ee ff 00 11 22 33 44 55 66 77 88] (and your CR_ST_BYTE() macro looks right for this). Grouping this into units of four bytes for the words array, we get [99 aa bb cc] [dd ee ff 00] [11 22 33 44] [55 66 77 88] resulting in values 0x99aabbcc 0xddeeff00 0x11223344 0x55667788 And then your CR_ST_WORD macro permutes them (1, 0, 3, 2) to the following values: 0xddeeff00 0x99aabbcc 0x55667788 0x11223344 ... Which is identical to the LE host result. So this part looks fine to me. Regarding the rest -- in my opinion, getting the implementation of crypto primitivies *wrong* despite them succesfully passing an extensive test suite is exceedingly unlikely. You usually cannot get crypto primitives "halfway right" -- as long as you don't *combine* them to bigger building blocks, crypto primitives are 100% specified and there are no "corner cases" that are usual for other program logic. The implementation either works or is catastrophically broken (which is quickly visible). Hence, if Peter gets good test results for this patchset, then I think that *suffices* to apply the patch. ... Which is why I won't try to eyeball the rest of the patch where you put the macros to use. :) The macros themselves are sound. If you broke their application, they won't pass the test suite (in the kernel bootup code, or elsewhere). Acked-by: Laszlo Ersek <lersek@redhat.com> Thanks Laszlo > +#else > +#define CR_ST_BYTE(state, i) (state.bytes[i]) > +#define CR_ST_WORD(state, i) (state.words[i]) > +#endif > + > void HELPER(crypto_aese)(CPUARMState *env, uint32_t rd, uint32_t rm, > uint32_t decrypt) > { > @@ -46,7 +54,7 @@ void HELPER(crypto_aese)(CPUARMState *env, uint32_t rd, uint32_t rm, > > /* combine ShiftRows operation and sbox substitution */ > for (i = 0; i < 16; i++) { > - st.bytes[i] = sbox[decrypt][rk.bytes[shift[decrypt][i]]]; > + CR_ST_BYTE(st, i) = sbox[decrypt][CR_ST_BYTE(rk, shift[decrypt][i])]; > } > > env->vfp.regs[rd] = make_float64(st.l[0]); > @@ -198,11 +206,11 @@ void HELPER(crypto_aesmc)(CPUARMState *env, uint32_t rd, uint32_t rm, > assert(decrypt < 2); > > for (i = 0; i < 16; i += 4) { > - st.words[i >> 2] = cpu_to_le32( > - mc[decrypt][st.bytes[i]] ^ > - rol32(mc[decrypt][st.bytes[i + 1]], 8) ^ > - rol32(mc[decrypt][st.bytes[i + 2]], 16) ^ > - rol32(mc[decrypt][st.bytes[i + 3]], 24)); > + CR_ST_WORD(st, i >> 2) = > + mc[decrypt][CR_ST_BYTE(st, i)] ^ > + rol32(mc[decrypt][CR_ST_BYTE(st, i + 1)], 8) ^ > + rol32(mc[decrypt][CR_ST_BYTE(st, i + 2)], 16) ^ > + rol32(mc[decrypt][CR_ST_BYTE(st, i + 3)], 24); > } > > env->vfp.regs[rd] = make_float64(st.l[0]); > @@ -255,24 +263,25 @@ void HELPER(crypto_sha1_3reg)(CPUARMState *env, uint32_t rd, uint32_t rn, > > switch (op) { > case 0: /* sha1c */ > - t = cho(d.words[1], d.words[2], d.words[3]); > + t = cho(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); > break; > case 1: /* sha1p */ > - t = par(d.words[1], d.words[2], d.words[3]); > + t = par(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); > break; > case 2: /* sha1m */ > - t = maj(d.words[1], d.words[2], d.words[3]); > + t = maj(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); > break; > default: > g_assert_not_reached(); > } > - t += rol32(d.words[0], 5) + n.words[0] + m.words[i]; > - > - n.words[0] = d.words[3]; > - d.words[3] = d.words[2]; > - d.words[2] = ror32(d.words[1], 2); > - d.words[1] = d.words[0]; > - d.words[0] = t; > + t += rol32(CR_ST_WORD(d, 0), 5) + CR_ST_WORD(n, 0) > + + CR_ST_WORD(m, i); > + > + CR_ST_WORD(n, 0) = CR_ST_WORD(d, 3); > + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); > + CR_ST_WORD(d, 2) = ror32(CR_ST_WORD(d, 1), 2); > + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); > + CR_ST_WORD(d, 0) = t; > } > } > env->vfp.regs[rd] = make_float64(d.l[0]); > @@ -286,8 +295,8 @@ void HELPER(crypto_sha1h)(CPUARMState *env, uint32_t rd, uint32_t rm) > float64_val(env->vfp.regs[rm + 1]) > } }; > > - m.words[0] = ror32(m.words[0], 2); > - m.words[1] = m.words[2] = m.words[3] = 0; > + CR_ST_WORD(m, 0) = ror32(CR_ST_WORD(m, 0), 2); > + CR_ST_WORD(m, 1) = CR_ST_WORD(m, 2) = CR_ST_WORD(m, 3) = 0; > > env->vfp.regs[rd] = make_float64(m.l[0]); > env->vfp.regs[rd + 1] = make_float64(m.l[1]); > @@ -304,10 +313,10 @@ void HELPER(crypto_sha1su1)(CPUARMState *env, uint32_t rd, uint32_t rm) > float64_val(env->vfp.regs[rm + 1]) > } }; > > - d.words[0] = rol32(d.words[0] ^ m.words[1], 1); > - d.words[1] = rol32(d.words[1] ^ m.words[2], 1); > - d.words[2] = rol32(d.words[2] ^ m.words[3], 1); > - d.words[3] = rol32(d.words[3] ^ d.words[0], 1); > + CR_ST_WORD(d, 0) = rol32(CR_ST_WORD(d, 0) ^ CR_ST_WORD(m, 1), 1); > + CR_ST_WORD(d, 1) = rol32(CR_ST_WORD(d, 1) ^ CR_ST_WORD(m, 2), 1); > + CR_ST_WORD(d, 2) = rol32(CR_ST_WORD(d, 2) ^ CR_ST_WORD(m, 3), 1); > + CR_ST_WORD(d, 3) = rol32(CR_ST_WORD(d, 3) ^ CR_ST_WORD(d, 0), 1); > > env->vfp.regs[rd] = make_float64(d.l[0]); > env->vfp.regs[rd + 1] = make_float64(d.l[1]); > @@ -356,20 +365,22 @@ void HELPER(crypto_sha256h)(CPUARMState *env, uint32_t rd, uint32_t rn, > int i; > > for (i = 0; i < 4; i++) { > - uint32_t t = cho(n.words[0], n.words[1], n.words[2]) + n.words[3] > - + S1(n.words[0]) + m.words[i]; > - > - n.words[3] = n.words[2]; > - n.words[2] = n.words[1]; > - n.words[1] = n.words[0]; > - n.words[0] = d.words[3] + t; > - > - t += maj(d.words[0], d.words[1], d.words[2]) + S0(d.words[0]); > - > - d.words[3] = d.words[2]; > - d.words[2] = d.words[1]; > - d.words[1] = d.words[0]; > - d.words[0] = t; > + uint32_t t = cho(CR_ST_WORD(n, 0), CR_ST_WORD(n, 1), CR_ST_WORD(n, 2)) > + + CR_ST_WORD(n, 3) + S1(CR_ST_WORD(n, 0)) > + + CR_ST_WORD(m, i); > + > + CR_ST_WORD(n, 3) = CR_ST_WORD(n, 2); > + CR_ST_WORD(n, 2) = CR_ST_WORD(n, 1); > + CR_ST_WORD(n, 1) = CR_ST_WORD(n, 0); > + CR_ST_WORD(n, 0) = CR_ST_WORD(d, 3) + t; > + > + t += maj(CR_ST_WORD(d, 0), CR_ST_WORD(d, 1), CR_ST_WORD(d, 2)) > + + S0(CR_ST_WORD(d, 0)); > + > + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); > + CR_ST_WORD(d, 2) = CR_ST_WORD(d, 1); > + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); > + CR_ST_WORD(d, 0) = t; > } > > env->vfp.regs[rd] = make_float64(d.l[0]); > @@ -394,13 +405,14 @@ void HELPER(crypto_sha256h2)(CPUARMState *env, uint32_t rd, uint32_t rn, > int i; > > for (i = 0; i < 4; i++) { > - uint32_t t = cho(d.words[0], d.words[1], d.words[2]) + d.words[3] > - + S1(d.words[0]) + m.words[i]; > - > - d.words[3] = d.words[2]; > - d.words[2] = d.words[1]; > - d.words[1] = d.words[0]; > - d.words[0] = n.words[3 - i] + t; > + uint32_t t = cho(CR_ST_WORD(d, 0), CR_ST_WORD(d, 1), CR_ST_WORD(d, 2)) > + + CR_ST_WORD(d, 3) + S1(CR_ST_WORD(d, 0)) > + + CR_ST_WORD(m, i); > + > + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); > + CR_ST_WORD(d, 2) = CR_ST_WORD(d, 1); > + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); > + CR_ST_WORD(d, 0) = CR_ST_WORD(n, 3 - i) + t; > } > > env->vfp.regs[rd] = make_float64(d.l[0]); > @@ -418,10 +430,10 @@ void HELPER(crypto_sha256su0)(CPUARMState *env, uint32_t rd, uint32_t rm) > float64_val(env->vfp.regs[rm + 1]) > } }; > > - d.words[0] += s0(d.words[1]); > - d.words[1] += s0(d.words[2]); > - d.words[2] += s0(d.words[3]); > - d.words[3] += s0(m.words[0]); > + CR_ST_WORD(d, 0) += s0(CR_ST_WORD(d, 1)); > + CR_ST_WORD(d, 1) += s0(CR_ST_WORD(d, 2)); > + CR_ST_WORD(d, 2) += s0(CR_ST_WORD(d, 3)); > + CR_ST_WORD(d, 3) += s0(CR_ST_WORD(m, 0)); > > env->vfp.regs[rd] = make_float64(d.l[0]); > env->vfp.regs[rd + 1] = make_float64(d.l[1]); > @@ -443,10 +455,10 @@ void HELPER(crypto_sha256su1)(CPUARMState *env, uint32_t rd, uint32_t rn, > float64_val(env->vfp.regs[rm + 1]) > } }; > > - d.words[0] += s1(m.words[2]) + n.words[1]; > - d.words[1] += s1(m.words[3]) + n.words[2]; > - d.words[2] += s1(d.words[0]) + n.words[3]; > - d.words[3] += s1(d.words[1]) + m.words[0]; > + CR_ST_WORD(d, 0) += s1(CR_ST_WORD(m, 2)) + CR_ST_WORD(n, 1); > + CR_ST_WORD(d, 1) += s1(CR_ST_WORD(m, 3)) + CR_ST_WORD(n, 2); > + CR_ST_WORD(d, 2) += s1(CR_ST_WORD(d, 0)) + CR_ST_WORD(n, 3); > + CR_ST_WORD(d, 3) += s1(CR_ST_WORD(d, 1)) + CR_ST_WORD(m, 0); > > env->vfp.regs[rd] = make_float64(d.l[0]); > env->vfp.regs[rd + 1] = make_float64(d.l[1]); > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-02 15:17 ` Laszlo Ersek @ 2015-01-02 17:36 ` Peter Maydell 2015-01-02 19:18 ` Laszlo Ersek 2015-01-02 19:21 ` Ard Biesheuvel 1 sibling, 1 reply; 8+ messages in thread From: Peter Maydell @ 2015-01-02 17:36 UTC (permalink / raw) To: Laszlo Ersek; +Cc: QEMU Developers, Ard Biesheuvel On 2 January 2015 at 15:17, Laszlo Ersek <lersek@redhat.com> wrote: > On 01/02/15 15:18, Ard Biesheuvel wrote: >> (ie if you store 0x112233445566778899aabbccddeeff00 as a 64 bit write >> to VFP register D0 then regs[0] will be >> 0x112233445566778899aabbccddeeff00 regardless of host endianness. That >> is, the least significant 8 bits of D0 will be (regs[0] & 0xff). (This >> isn't the same number as if you do the union-type-punning thing with >> union { uint64_t l; uint8_t b[8]; } and look at b[0].) This example is confusing because I carefully said "64 bit write" and then used a 128 bit constant. What I meant was: ie if you store 0x1122334455667788 as a 64 bit write to VFP register D0 then regs[0] will be 0x1122334455667788 regardless of host endianness. For 128 bit vectors, if you store 0x112233445566778899aabbccddeeff00 to Q0 then you get regs[0] == 0x99aabbccddeeff00 regs[1] == 0x1122334455667788 (as is required architecturally in order for a subsequent guest read from D0 to do the right thing). -- PMM ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-02 17:36 ` Peter Maydell @ 2015-01-02 19:18 ` Laszlo Ersek 0 siblings, 0 replies; 8+ messages in thread From: Laszlo Ersek @ 2015-01-02 19:18 UTC (permalink / raw) To: Peter Maydell; +Cc: QEMU Developers, Ard Biesheuvel On 01/02/15 18:36, Peter Maydell wrote: > On 2 January 2015 at 15:17, Laszlo Ersek <lersek@redhat.com> wrote: >> On 01/02/15 15:18, Ard Biesheuvel wrote: >>> (ie if you store 0x112233445566778899aabbccddeeff00 as a 64 bit write >>> to VFP register D0 then regs[0] will be >>> 0x112233445566778899aabbccddeeff00 regardless of host endianness. That >>> is, the least significant 8 bits of D0 will be (regs[0] & 0xff). (This >>> isn't the same number as if you do the union-type-punning thing with >>> union { uint64_t l; uint8_t b[8]; } and look at b[0].) > > This example is confusing because I carefully said "64 bit write" > and then used a 128 bit constant. What I meant was: > > ie if you store 0x1122334455667788 as a 64 bit write > to VFP register D0 then regs[0] will be > 0x1122334455667788 regardless of host endianness. > > For 128 bit vectors, if you store > 0x112233445566778899aabbccddeeff00 to Q0 then you get > regs[0] == 0x99aabbccddeeff00 > regs[1] == 0x1122334455667788 > > (as is required architecturally in order for a subsequent guest > read from D0 to do the right thing). Thank you for the correction -- but I think that's exactly what I worked with in the rest of my email, don't you find? Thanks Laszlo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-02 15:17 ` Laszlo Ersek 2015-01-02 17:36 ` Peter Maydell @ 2015-01-02 19:21 ` Ard Biesheuvel 2015-01-05 12:34 ` Peter Maydell 1 sibling, 1 reply; 8+ messages in thread From: Ard Biesheuvel @ 2015-01-02 19:21 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Peter Maydell, QEMU Developers On 2 January 2015 at 15:17, Laszlo Ersek <lersek@redhat.com> wrote: > On 01/02/15 15:18, Ard Biesheuvel wrote: >> The crypto emulation code in target-arm/crypto_helper.c never worked >> correctly on big endian hosts, due to the fact that it uses a union >> of array types to convert between the native VFP register size (64 >> bits) and the types used in the algorithms (bytes and 32 bit words) >> >> We cannot just swab between LE and BE when reading and writing the >> registers, as the SHA code performs word additions, so instead, add >> array accessors for the CRYPTO_STATE type whose LE and BE specific >> implementations ensure that the correct array elements are referenced. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> --- >> >> Only tested on a LE (amd64) host, as I don't have access to a BE host. >> >> target-arm/crypto_helper.c | 114 +++++++++++++++++++++++++-------------------- >> 1 file changed, 63 insertions(+), 51 deletions(-) >> >> diff --git a/target-arm/crypto_helper.c b/target-arm/crypto_helper.c >> index dd60d0b81a4c..1fe975d0f1e3 100644 >> --- a/target-arm/crypto_helper.c >> +++ b/target-arm/crypto_helper.c >> @@ -22,6 +22,14 @@ union CRYPTO_STATE { >> uint64_t l[2]; >> }; >> >> +#ifdef HOST_WORDS_BIGENDIAN >> +#define CR_ST_BYTE(state, i) (state.bytes[(15 - (i)) ^ 8]) > > Produces > > 7, 6, 5, 4, 3, 2, 1, 0, > 15, 14, 13, 12, 11, 10, 9 > > which I think is consistent with what Peter wrote. > >> +#define CR_ST_WORD(state, i) (state.words[(3 - (i)) ^ 2]) > > Hm. The indices look good: > > 1, 0 > 3, 2 > > But, assuming you're on a big-endian host, perhaps you should byte swap > the uint32_t too?... > No, I don't think so. I even removed the cpu_to_le32() call from the aesmc helper because the MixColumns lookup tables will be emitted in host native endianness, and the vfp.regs[] array is host native endianness as well. I think the union type may have been a mistake to begin with, because it introduces endianness dependencies that don't actually exist in the code. It probably would have been cleaner if I had defined the relation between VFP D-regs, words and bytes in terms of shifts and masks instead. >> (ie if you store 0x112233445566778899aabbccddeeff00 as a 64 bit write >> to VFP register D0 then regs[0] will be >> 0x112233445566778899aabbccddeeff00 regardless of host endianness. That >> is, the least significant 8 bits of D0 will be (regs[0] & 0xff). (This >> isn't the same number as if you do the union-type-punning thing with >> union { uint64_t l; uint8_t b[8]; } and look at b[0].) > > Assume the guest writes value 0x112233445566778899aabbccddeeff00 (LE > representation). > > * Assuming a little endian host, we get: > > [00 ff ee dd cc bb aa 99 88 77 66 55 44 33 22 11] > > (full 128-bit LE vector). > > This is grouped into units of four bytes for the words array: > > [00 ff ee dd] [cc bb aa 99] [88 77 66 55] [44 33 22 11] > > And the meaning of the individual uint32_t's is: > > 0xddeeff00 0x99aabbcc 0x55667788 0x11223344 > > Which are the building blocks for the crypto primitives. > > * Assuming a big endian host, you get the following byte array for the > same store (if I understand Peter right -- two uint64_t values are > encoded as host endian, but the ordering between those remains little > endian): > > [99 aa bb cc dd ee ff 00 11 22 33 44 55 66 77 88] > > (and your CR_ST_BYTE() macro looks right for this). > > Grouping this into units of four bytes for the words array, we get > > [99 aa bb cc] [dd ee ff 00] [11 22 33 44] [55 66 77 88] > > resulting in values > > 0x99aabbcc 0xddeeff00 0x11223344 0x55667788 > > And then your CR_ST_WORD macro permutes them (1, 0, 3, 2) to the > following values: > > 0xddeeff00 0x99aabbcc 0x55667788 0x11223344 > > ... Which is identical to the LE host result. > > So this part looks fine to me. > Thanks for the elaborate review. > Regarding the rest -- in my opinion, getting the implementation of > crypto primitivies *wrong* despite them succesfully passing an extensive > test suite is exceedingly unlikely. You usually cannot get crypto > primitives "halfway right" -- as long as you don't *combine* them to > bigger building blocks, crypto primitives are 100% specified and there > are no "corner cases" that are usual for other program logic. The > implementation either works or is catastrophically broken (which is > quickly visible). > > Hence, if Peter gets good test results for this patchset, then I think > that *suffices* to apply the patch. > Agreed. > ... Which is why I won't try to eyeball the rest of the patch where you > put the macros to use. :) The macros themselves are sound. If you broke > their application, they won't pass the test suite (in the kernel bootup > code, or elsewhere). > > Acked-by: Laszlo Ersek <lersek@redhat.com> > > Thanks > Laszlo > Cheers, Ard. >> +#else >> +#define CR_ST_BYTE(state, i) (state.bytes[i]) >> +#define CR_ST_WORD(state, i) (state.words[i]) >> +#endif >> + >> void HELPER(crypto_aese)(CPUARMState *env, uint32_t rd, uint32_t rm, >> uint32_t decrypt) >> { >> @@ -46,7 +54,7 @@ void HELPER(crypto_aese)(CPUARMState *env, uint32_t rd, uint32_t rm, >> >> /* combine ShiftRows operation and sbox substitution */ >> for (i = 0; i < 16; i++) { >> - st.bytes[i] = sbox[decrypt][rk.bytes[shift[decrypt][i]]]; >> + CR_ST_BYTE(st, i) = sbox[decrypt][CR_ST_BYTE(rk, shift[decrypt][i])]; >> } >> >> env->vfp.regs[rd] = make_float64(st.l[0]); >> @@ -198,11 +206,11 @@ void HELPER(crypto_aesmc)(CPUARMState *env, uint32_t rd, uint32_t rm, >> assert(decrypt < 2); >> >> for (i = 0; i < 16; i += 4) { >> - st.words[i >> 2] = cpu_to_le32( >> - mc[decrypt][st.bytes[i]] ^ >> - rol32(mc[decrypt][st.bytes[i + 1]], 8) ^ >> - rol32(mc[decrypt][st.bytes[i + 2]], 16) ^ >> - rol32(mc[decrypt][st.bytes[i + 3]], 24)); >> + CR_ST_WORD(st, i >> 2) = >> + mc[decrypt][CR_ST_BYTE(st, i)] ^ >> + rol32(mc[decrypt][CR_ST_BYTE(st, i + 1)], 8) ^ >> + rol32(mc[decrypt][CR_ST_BYTE(st, i + 2)], 16) ^ >> + rol32(mc[decrypt][CR_ST_BYTE(st, i + 3)], 24); >> } >> >> env->vfp.regs[rd] = make_float64(st.l[0]); >> @@ -255,24 +263,25 @@ void HELPER(crypto_sha1_3reg)(CPUARMState *env, uint32_t rd, uint32_t rn, >> >> switch (op) { >> case 0: /* sha1c */ >> - t = cho(d.words[1], d.words[2], d.words[3]); >> + t = cho(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); >> break; >> case 1: /* sha1p */ >> - t = par(d.words[1], d.words[2], d.words[3]); >> + t = par(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); >> break; >> case 2: /* sha1m */ >> - t = maj(d.words[1], d.words[2], d.words[3]); >> + t = maj(CR_ST_WORD(d, 1), CR_ST_WORD(d, 2), CR_ST_WORD(d, 3)); >> break; >> default: >> g_assert_not_reached(); >> } >> - t += rol32(d.words[0], 5) + n.words[0] + m.words[i]; >> - >> - n.words[0] = d.words[3]; >> - d.words[3] = d.words[2]; >> - d.words[2] = ror32(d.words[1], 2); >> - d.words[1] = d.words[0]; >> - d.words[0] = t; >> + t += rol32(CR_ST_WORD(d, 0), 5) + CR_ST_WORD(n, 0) >> + + CR_ST_WORD(m, i); >> + >> + CR_ST_WORD(n, 0) = CR_ST_WORD(d, 3); >> + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); >> + CR_ST_WORD(d, 2) = ror32(CR_ST_WORD(d, 1), 2); >> + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); >> + CR_ST_WORD(d, 0) = t; >> } >> } >> env->vfp.regs[rd] = make_float64(d.l[0]); >> @@ -286,8 +295,8 @@ void HELPER(crypto_sha1h)(CPUARMState *env, uint32_t rd, uint32_t rm) >> float64_val(env->vfp.regs[rm + 1]) >> } }; >> >> - m.words[0] = ror32(m.words[0], 2); >> - m.words[1] = m.words[2] = m.words[3] = 0; >> + CR_ST_WORD(m, 0) = ror32(CR_ST_WORD(m, 0), 2); >> + CR_ST_WORD(m, 1) = CR_ST_WORD(m, 2) = CR_ST_WORD(m, 3) = 0; >> >> env->vfp.regs[rd] = make_float64(m.l[0]); >> env->vfp.regs[rd + 1] = make_float64(m.l[1]); >> @@ -304,10 +313,10 @@ void HELPER(crypto_sha1su1)(CPUARMState *env, uint32_t rd, uint32_t rm) >> float64_val(env->vfp.regs[rm + 1]) >> } }; >> >> - d.words[0] = rol32(d.words[0] ^ m.words[1], 1); >> - d.words[1] = rol32(d.words[1] ^ m.words[2], 1); >> - d.words[2] = rol32(d.words[2] ^ m.words[3], 1); >> - d.words[3] = rol32(d.words[3] ^ d.words[0], 1); >> + CR_ST_WORD(d, 0) = rol32(CR_ST_WORD(d, 0) ^ CR_ST_WORD(m, 1), 1); >> + CR_ST_WORD(d, 1) = rol32(CR_ST_WORD(d, 1) ^ CR_ST_WORD(m, 2), 1); >> + CR_ST_WORD(d, 2) = rol32(CR_ST_WORD(d, 2) ^ CR_ST_WORD(m, 3), 1); >> + CR_ST_WORD(d, 3) = rol32(CR_ST_WORD(d, 3) ^ CR_ST_WORD(d, 0), 1); >> >> env->vfp.regs[rd] = make_float64(d.l[0]); >> env->vfp.regs[rd + 1] = make_float64(d.l[1]); >> @@ -356,20 +365,22 @@ void HELPER(crypto_sha256h)(CPUARMState *env, uint32_t rd, uint32_t rn, >> int i; >> >> for (i = 0; i < 4; i++) { >> - uint32_t t = cho(n.words[0], n.words[1], n.words[2]) + n.words[3] >> - + S1(n.words[0]) + m.words[i]; >> - >> - n.words[3] = n.words[2]; >> - n.words[2] = n.words[1]; >> - n.words[1] = n.words[0]; >> - n.words[0] = d.words[3] + t; >> - >> - t += maj(d.words[0], d.words[1], d.words[2]) + S0(d.words[0]); >> - >> - d.words[3] = d.words[2]; >> - d.words[2] = d.words[1]; >> - d.words[1] = d.words[0]; >> - d.words[0] = t; >> + uint32_t t = cho(CR_ST_WORD(n, 0), CR_ST_WORD(n, 1), CR_ST_WORD(n, 2)) >> + + CR_ST_WORD(n, 3) + S1(CR_ST_WORD(n, 0)) >> + + CR_ST_WORD(m, i); >> + >> + CR_ST_WORD(n, 3) = CR_ST_WORD(n, 2); >> + CR_ST_WORD(n, 2) = CR_ST_WORD(n, 1); >> + CR_ST_WORD(n, 1) = CR_ST_WORD(n, 0); >> + CR_ST_WORD(n, 0) = CR_ST_WORD(d, 3) + t; >> + >> + t += maj(CR_ST_WORD(d, 0), CR_ST_WORD(d, 1), CR_ST_WORD(d, 2)) >> + + S0(CR_ST_WORD(d, 0)); >> + >> + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); >> + CR_ST_WORD(d, 2) = CR_ST_WORD(d, 1); >> + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); >> + CR_ST_WORD(d, 0) = t; >> } >> >> env->vfp.regs[rd] = make_float64(d.l[0]); >> @@ -394,13 +405,14 @@ void HELPER(crypto_sha256h2)(CPUARMState *env, uint32_t rd, uint32_t rn, >> int i; >> >> for (i = 0; i < 4; i++) { >> - uint32_t t = cho(d.words[0], d.words[1], d.words[2]) + d.words[3] >> - + S1(d.words[0]) + m.words[i]; >> - >> - d.words[3] = d.words[2]; >> - d.words[2] = d.words[1]; >> - d.words[1] = d.words[0]; >> - d.words[0] = n.words[3 - i] + t; >> + uint32_t t = cho(CR_ST_WORD(d, 0), CR_ST_WORD(d, 1), CR_ST_WORD(d, 2)) >> + + CR_ST_WORD(d, 3) + S1(CR_ST_WORD(d, 0)) >> + + CR_ST_WORD(m, i); >> + >> + CR_ST_WORD(d, 3) = CR_ST_WORD(d, 2); >> + CR_ST_WORD(d, 2) = CR_ST_WORD(d, 1); >> + CR_ST_WORD(d, 1) = CR_ST_WORD(d, 0); >> + CR_ST_WORD(d, 0) = CR_ST_WORD(n, 3 - i) + t; >> } >> >> env->vfp.regs[rd] = make_float64(d.l[0]); >> @@ -418,10 +430,10 @@ void HELPER(crypto_sha256su0)(CPUARMState *env, uint32_t rd, uint32_t rm) >> float64_val(env->vfp.regs[rm + 1]) >> } }; >> >> - d.words[0] += s0(d.words[1]); >> - d.words[1] += s0(d.words[2]); >> - d.words[2] += s0(d.words[3]); >> - d.words[3] += s0(m.words[0]); >> + CR_ST_WORD(d, 0) += s0(CR_ST_WORD(d, 1)); >> + CR_ST_WORD(d, 1) += s0(CR_ST_WORD(d, 2)); >> + CR_ST_WORD(d, 2) += s0(CR_ST_WORD(d, 3)); >> + CR_ST_WORD(d, 3) += s0(CR_ST_WORD(m, 0)); >> >> env->vfp.regs[rd] = make_float64(d.l[0]); >> env->vfp.regs[rd + 1] = make_float64(d.l[1]); >> @@ -443,10 +455,10 @@ void HELPER(crypto_sha256su1)(CPUARMState *env, uint32_t rd, uint32_t rn, >> float64_val(env->vfp.regs[rm + 1]) >> } }; >> >> - d.words[0] += s1(m.words[2]) + n.words[1]; >> - d.words[1] += s1(m.words[3]) + n.words[2]; >> - d.words[2] += s1(d.words[0]) + n.words[3]; >> - d.words[3] += s1(d.words[1]) + m.words[0]; >> + CR_ST_WORD(d, 0) += s1(CR_ST_WORD(m, 2)) + CR_ST_WORD(n, 1); >> + CR_ST_WORD(d, 1) += s1(CR_ST_WORD(m, 3)) + CR_ST_WORD(n, 2); >> + CR_ST_WORD(d, 2) += s1(CR_ST_WORD(d, 0)) + CR_ST_WORD(n, 3); >> + CR_ST_WORD(d, 3) += s1(CR_ST_WORD(d, 1)) + CR_ST_WORD(m, 0); >> >> env->vfp.regs[rd] = make_float64(d.l[0]); >> env->vfp.regs[rd + 1] = make_float64(d.l[1]); >> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-02 19:21 ` Ard Biesheuvel @ 2015-01-05 12:34 ` Peter Maydell 2015-01-05 13:47 ` Ard Biesheuvel 0 siblings, 1 reply; 8+ messages in thread From: Peter Maydell @ 2015-01-05 12:34 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: Laszlo Ersek, QEMU Developers On 2 January 2015 at 19:21, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > I think the union type may have been a mistake to > begin with, because it introduces endianness dependencies that don't > actually exist in the code. It probably would have been cleaner if I > had defined the relation between VFP D-regs, words and bytes in terms > of shifts and masks instead. Mmm, I think in retrospect this is right. Still, this patch does cause the kernel's self-tests on boot on a BE ppc64 host to pass, and looking through the code we haven't missed any accesses to .bytes or .words, so it looks good to me. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> -- PMM ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-05 12:34 ` Peter Maydell @ 2015-01-05 13:47 ` Ard Biesheuvel 2015-01-05 13:58 ` Peter Maydell 0 siblings, 1 reply; 8+ messages in thread From: Ard Biesheuvel @ 2015-01-05 13:47 UTC (permalink / raw) To: Peter Maydell; +Cc: Laszlo Ersek, QEMU Developers On 5 January 2015 at 12:34, Peter Maydell <peter.maydell@linaro.org> wrote: > On 2 January 2015 at 19:21, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: >> I think the union type may have been a mistake to >> begin with, because it introduces endianness dependencies that don't >> actually exist in the code. It probably would have been cleaner if I >> had defined the relation between VFP D-regs, words and bytes in terms >> of shifts and masks instead. > > Mmm, I think in retrospect this is right. Still, this patch does > cause the kernel's self-tests on boot on a BE ppc64 host to pass, > and looking through the code we haven't missed any accesses to > .bytes or .words, so it looks good to me. > > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > OK, good, thanks for testing. I propose we leave the patch as-is then. Are you ok to add the tags and merge it? Cheers, Ard. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support 2015-01-05 13:47 ` Ard Biesheuvel @ 2015-01-05 13:58 ` Peter Maydell 0 siblings, 0 replies; 8+ messages in thread From: Peter Maydell @ 2015-01-05 13:58 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: Laszlo Ersek, QEMU Developers On 5 January 2015 at 13:47, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 5 January 2015 at 12:34, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 2 January 2015 at 19:21, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: >>> I think the union type may have been a mistake to >>> begin with, because it introduces endianness dependencies that don't >>> actually exist in the code. It probably would have been cleaner if I >>> had defined the relation between VFP D-regs, words and bytes in terms >>> of shifts and masks instead. >> >> Mmm, I think in retrospect this is right. Still, this patch does >> cause the kernel's self-tests on boot on a BE ppc64 host to pass, >> and looking through the code we haven't missed any accesses to >> .bytes or .words, so it looks good to me. >> >> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> >> > > OK, good, thanks for testing. > > I propose we leave the patch as-is then. Are you ok to add the tags > and merge it? Yep; I've put it into target-arm.next. -- PMM ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-01-05 13:59 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-01-02 14:18 [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support Ard Biesheuvel 2015-01-02 15:17 ` Laszlo Ersek 2015-01-02 17:36 ` Peter Maydell 2015-01-02 19:18 ` Laszlo Ersek 2015-01-02 19:21 ` Ard Biesheuvel 2015-01-05 12:34 ` Peter Maydell 2015-01-05 13:47 ` Ard Biesheuvel 2015-01-05 13:58 ` Peter Maydell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).