On Sat, 2018-08-04 at 11:01 +0200, Greg Kroah-Hartman wrote:
4.4-stable review patch. If anyone has any objections, please let me know.
From: Herbert Xu herbert@gondor.apana.org.au
commit 46d8c4b28652d35dc6cfb5adf7f54e102fc04384 upstream.
This was detected by the self-test thanks to Ard's chunking patch.
I finally got around to testing this out on my ancient Via box. It turns out that the workaround got the assembly wrong and we end up doing count + initial cycles of the loop instead of just count.
This obviously causes corruption, either by overwriting the source that is yet to be processed, or writing over the end of the buffer.
On CPUs that don't require the workaround only ECB is affected. On Nano CPUs both ECB and CBC are affected.
This patch fixes it by doing the subtraction prior to the assembly.
[...]
--- a/drivers/crypto/padlock-aes.c +++ b/drivers/crypto/padlock-aes.c @@ -266,6 +266,8 @@ static inline void padlock_xcrypt_ecb(co
return; }
- count -= initial;
if (initial) asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */ : "+S"(input), "+D"(output) @@ -273,7 +275,7 @@ static inline void padlock_xcrypt_ecb(co asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */ : "+S"(input), "+D"(output)
: "d"(control_word), "b"(key), "c"(count - initial));
: "d"(control_word), "b"(key), "c"(count));} static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
[...]
On the face of it, this change shouldn't make any difference. But I think what's going on is that the compiler stores "initial" in register ecx and nowhere else, because it has no idea that the first inline assembly block will update ecx.
This change evidently works around that problem for the specific compiler and configuration you tested with, but it seems fragile. I think the assembly constraints should be updated to properly fix this.
Ben.