diff options
author | David S. Miller <davem@davemloft.net> | 2012-12-19 15:19:11 -0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2012-12-19 15:19:11 -0800 |
commit | 9f28ffc03e93343ac04874fda9edb7affea45165 (patch) | |
tree | 5d65df3dacd78570469a5c1183359595015fdd9b /drivers/iio | |
parent | 4a9d1946b0135b15d901d7e7c9796d36f352aaea (diff) | |
download | linux-stable-9f28ffc03e93343ac04874fda9edb7affea45165.tar.gz linux-stable-9f28ffc03e93343ac04874fda9edb7affea45165.tar.bz2 linux-stable-9f28ffc03e93343ac04874fda9edb7affea45165.zip |
sparc64: Fix unrolled AES 256-bit key loops.
The basic scheme of the block mode assembler is that we start by
enabling the FPU, loading the key into the floating point registers,
then iterate calling the encrypt/decrypt routine for each block.
For the 256-bit key cases, we run short on registers in the unrolled
loops.
So the {ENCRYPT,DECRYPT}_256_2() macros reload the key registers that
get clobbered.
The unrolled macros, {ENCRYPT,DECRYPT}_256(), are not mindful of this.
So if we have a mix of multi-block and single-block calls, the
single-block unrolled 256-bit encrypt/decrypt can run with some
of the key registers clobbered.
Handle this by always explicitly loading those registers before using
the non-unrolled 256-bit macro.
This was discovered thanks to all of the new test cases added by
Jussi Kivilinna.
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/iio')
0 files changed, 0 insertions, 0 deletions