• David S. Miller's avatar
    sparc64: Fix FPU register corruption with AES crypto offload. · f4da3628
    David S. Miller authored
    The AES loops in arch/sparc/crypto/aes_glue.c use a scheme where the
    key material is preloaded into the FPU registers, and then we loop
    over and over doing the crypt operation, reusing those pre-cooked key
    registers.
    
    There are intervening blkcipher*() calls between the crypt operation
    calls.  And those might perform memcpy() and thus also try to use the
    FPU.
    
    The sparc64 kernel FPU usage mechanism is designed to allow such
    recursive uses, but with a catch.
    
    There has to be a trap between the two FPU using threads of control.
    
    The mechanism works by, when the FPU is already in use by the kernel,
    allocating a slot for FPU saving at trap time.  Then if, within the
    trap handler, we try to use the FPU registers, the pre-trap FPU
    register state is saved into the slot.  Then at trap return time we
    notice this and restore the pre-trap FPU state.
    
    Over the long term there are various more involved ways we can make
    this work, but for a quick fix let's take advantage of the fact that
    the situation where this happens is very limited.
    
    All sparc64 chips that support the crypto instructiosn also are using
    the Niagara4 memcpy routine, and that routine only uses the FPU for
    large copies where we can't get the source aligned properly to a
    multiple of 8 bytes.
    
    We look to see if the FPU is already in use in this context, and if so
    we use the non-large copy path which only uses integer registers.
    
    Furthermore, we also limit this special logic to when we are doing
    kernel copy, rather than a user copy.
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    f4da3628
NG4memcpy.S 8.36 KB