[PATCH 0/4] crypto: decrease priority of multibuffer SHA algorithms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Eric Biggers <ebiggers@xxxxxxxxxx>

I found that not only was sha256_mb sometimes computing the wrong digest
(fixed by a separately sent patch), but under normal workloads it's
hundreds of times slower than sha256-avx2, due to the flush delay.  The
same applies to sha1_mb and sha512_mb.  Yet, currently these can be the
highest priority implementations and therefore used by default.
Therefore, this series decreases their priority so that users have to
more explicitly opt-in to using them.

Note that I don't believe the status quo of just having them behind
kernel config options is sufficient, since people often aren't familiar
with all the crypto options and error on the side of enabling too many.
And it's especially unexpected that enabling an "optimized"
implementation would actually make things 1000 times slower.

Eric Biggers (4):
  crypto: sha1_generic - add cra_priority
  crypto: sha256_generic - add cra_priority
  crypto: sha512_generic - add cra_priority
  crypto: x86/sha-mb - decrease priority of multibuffer algorithms

 arch/x86/crypto/sha1-mb/sha1_mb.c     | 9 ++++++++-
 arch/x86/crypto/sha256-mb/sha256_mb.c | 9 ++++++++-
 arch/x86/crypto/sha512-mb/sha512_mb.c | 9 ++++++++-
 crypto/sha1_generic.c                 | 1 +
 crypto/sha256_generic.c               | 2 ++
 crypto/sha512_generic.c               | 2 ++
 6 files changed, 29 insertions(+), 3 deletions(-)

-- 
2.18.0.399.gad0ab374a1-goog




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux