Skip to content

K
Kernel

openeuler / Kernel
11 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 30 11月, 2011 1 次提交
  3. 21 11月, 2011 2 次提交
  5. 09 11月, 2011 1 次提交
  7. 01 11月, 2011 1 次提交
  9. 26 10月, 2011 1 次提交
  11. 21 10月, 2011 2 次提交
  13. 22 9月, 2011 2 次提交
  15. 10 8月, 2011 1 次提交
    • M
      crypto: sha1 - SSSE3 based SHA1 implementation for x86-64 · 66be8951
      由 Mathias Krause 提交于 
      This is an assembler implementation of the SHA1 algorithm using the
Supplemental SSE3 (SSSE3) instructions or, when available, the
Advanced Vector Extensions (AVX).

Testing with the tcrypt module shows the raw hash performance is up to
2.3 times faster than the C implementation, using 8k data blocks on a
Core 2 Duo T5500. For the smalest data set (16 byte) it is still 25%
faster.

Since this implementation uses SSE/YMM registers it cannot safely be
used in every situation, e.g. while an IRQ interrupts a kernel thread.
The implementation falls back to the generic SHA1 variant, if using
the SSE/YMM registers is not possible.

With this algorithm I was able to increase the throughput of a single
IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using
the SSSE3 variant -- a speedup of +34.8%.

Saving and restoring SSE/YMM state might make the actual throughput
fluctuate when there are FPU intensive userland applications running.
For example, meassuring the performance using iperf2 directly on the
machine under test gives wobbling numbers because iperf2 uses the FPU
for each packet to check if the reporting interval has expired (in the
above test I got min/max/avg: 402/484/464 MBit/s).

Using this algorithm on a IPsec gateway gives much more reasonable and
stable numbers, albeit not as high as in the directly connected case.
Here is the result from an RFC 2544 test run with a EXFO Packet Blazer
FTB-8510:

 frame size    sha1-generic     sha1-ssse3    delta
    64 byte     37.5 MBit/s    37.5 MBit/s     0.0%
   128 byte     56.3 MBit/s    62.5 MBit/s   +11.0%
   256 byte     87.5 MBit/s   100.0 MBit/s   +14.3%
   512 byte    131.3 MBit/s   150.0 MBit/s   +14.2%
  1024 byte    162.5 MBit/s   193.8 MBit/s   +19.3%
  1280 byte    175.0 MBit/s   212.5 MBit/s   +21.4%
  1420 byte    175.0 MBit/s   218.7 MBit/s   +25.0%
  1518 byte    150.0 MBit/s   181.2 MBit/s   +20.8%

The throughput for the largest frame size is lower than for the
previous size because the IP packets need to be fragmented in this
case to make there way through the IPsec tunnel.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Cc: Maxim Locktyukhin <maxim.locktyukhin@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      66be8951
  17. 11 7月, 2011 1 次提交
  19. 30 6月, 2011 1 次提交
  21. 16 5月, 2011 1 次提交
  23. 28 12月, 2010 1 次提交
  25. 29 11月, 2010 1 次提交
  27. 27 11月, 2010 1 次提交
    • M
      crypto: aesni-intel - Ported implementation to x86-32 · 0d258efb
      由 Mathias Krause 提交于 
      The AES-NI instructions are also available in legacy mode so the 32-bit
architecture may profit from those, too.

To illustrate the performance gain here's a short summary of a dm-crypt
speed test on a Core i7 M620 running at 2.67GHz comparing both assembler
implementations:

x86:                   i568       aes-ni    delta
ECB, 256 bit:     93.8 MB/s   123.3 MB/s   +31.4%
CBC, 256 bit:     84.8 MB/s   262.3 MB/s  +209.3%
LRW, 256 bit:    108.6 MB/s   222.1 MB/s  +104.5%
XTS, 256 bit:    105.0 MB/s   205.5 MB/s   +95.7%

Additionally, due to some minor optimizations, the 64-bit version also
got a minor performance gain as seen below:

x86-64:           old impl.    new impl.    delta
ECB, 256 bit:    121.1 MB/s   123.0 MB/s    +1.5%
CBC, 256 bit:    285.3 MB/s   290.8 MB/s    +1.9%
LRW, 256 bit:    263.7 MB/s   265.3 MB/s    +0.6%
XTS, 256 bit:    251.1 MB/s   255.3 MB/s    +1.7%
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d258efb
  29. 26 11月, 2010 1 次提交
    • H
      crypto: algif_skcipher - User-space interface for skcipher operations · 8ff59090
      由 Herbert Xu 提交于 
      This patch adds the af_alg plugin for symmetric key ciphers,
corresponding to the ablkcipher kernel operation type.

Keys can optionally be set through the setsockopt interface.

Once a sendmsg call occurs without MSG_MORE no further writes
may be made to the socket until all previous data has been read.

IVs and and whether encryption/decryption is performed can be
set through the setsockopt interface or as a control message
to sendmsg.

The interface is completely synchronous, all operations are
carried out in recvmsg(2) and will complete prior to the system
call returning.

The splice(2) interface support reading the user-space data directly
without copying (except that the Crypto API itself may copy the data
if alignment is off).

The recvmsg(2) interface supports directly writing to user-space
without additional copying, i.e., the kernel crypto interface will
receive the user-space address as its output SG list.

Thakns to Miloslav Trmac for reviewing this and contributing
fixes and improvements.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NDavid S. Miller <davem@davemloft.net>
      8ff59090
  31. 19 11月, 2010 2 次提交
    • H
      crypto: algif_hash - User-space interface for hash operations · fe869cdb
      由 Herbert Xu 提交于 
      This patch adds the af_alg plugin for hash, corresponding to
the ahash kernel operation type.

Keys can optionally be set through the setsockopt interface.

Each sendmsg call will finalise the hash unless sent with a MSG_MORE
flag.

Partial hash states can be cloned using accept(2).

The interface is completely synchronous, all operations will
complete prior to the system call returning.

Both sendmsg(2) and splice(2) support reading the user-space
data directly without copying (except that the Crypto API itself
may copy the data if alignment is off).

For now only the splice(2) interface supports performing digest
instead of init/update/final.  In future the sendmsg(2) interface
will also be modified to use digest/finup where possible so that
hardware that cannot return a partial hash state can still benefit
from this interface.

Thakns to Miloslav Trmac for reviewing this and contributing
fixes and improvements.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Tested-by: NMartin Willi <martin@strongswan.org>
      fe869cdb
    • H
      crypto: af_alg - User-space interface for Crypto API · 03c8efc1
      由 Herbert Xu 提交于 
      This patch creates the backbone of the user-space interface for
the Crypto API, through a new socket family AF_ALG.

Each session corresponds to one or more connections obtained from
that socket.  The number depends on the number of inputs/outputs
of that particular type of operation.  For most types there will
be a s ingle connection/file descriptor that is used for both input
and output.  AEAD is one of the few that require two inputs.

Each algorithm type will provide its own implementation that plugs
into af_alg.  They're keyed using a string such as "skcipher" or
"hash".

IOW this patch only contains the boring bits that is required
to hold everything together.

Thakns to Miloslav Trmac for reviewing this and contributing
fixes and improvements.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Tested-by: NMartin Willi <martin@strongswan.org>
      03c8efc1
  33. 12 9月, 2010 1 次提交
  35. 03 9月, 2010 1 次提交
  37. 06 8月, 2010 2 次提交
    • H
      crypto: testmgr - Default to no tests · 00ca28a5
      由 Herbert Xu 提交于 
      On Thu, Aug 05, 2010 at 07:01:21PM -0700, Linus Torvalds wrote:
> On Thu, Aug 5, 2010 at 6:40 PM, Herbert Xu <herbert@gondor.hengli.com.au> wrote:
> >
> > -config CRYPTO_MANAGER_TESTS
> > -       bool "Run algolithms' self-tests"
> > -       default y
> > -       depends on CRYPTO_MANAGER2
> > +config CRYPTO_MANAGER_DISABLE_TESTS
> > +       bool "Disable run-time self tests"
> > +       depends on CRYPTO_MANAGER2 && EMBEDDED
>
> Why do you still want to force-enable those tests? I was going to
> complain about the "default y" anyway, now I'm _really_ complaining,
> because you've now made it impossible to disable those tests. Why?

As requested, this patch sets the default to y and removes the
EMBEDDED dependency.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      00ca28a5
    • H
      crypto: testmgr - Fix test disabling option · 326a6346
      由 Herbert Xu 提交于 
      This patch fixes a serious bug in the test disabling patch where
it can cause an spurious load of the cryptomgr module even when
it's compiled in.

It also negates the test disabling option so that its absence
causes tests to be enabled.

The Kconfig option is also now behind EMBEDDED.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      326a6346
  39. 03 6月, 2010 2 次提交
  41. 29 3月, 2010 1 次提交
  43. 05 2月, 2010 1 次提交
  45. 07 1月, 2010 1 次提交
  47. 27 10月, 2009 1 次提交
  49. 19 10月, 2009 1 次提交
  51. 02 9月, 2009 1 次提交
  53. 20 8月, 2009 1 次提交
    • N
      crypto: fips - Depend on ansi_cprng · 4e4ed83b
      由 Neil Horman 提交于 
      What about something like this?  It defaults the CPRNG to m and makes FIPS
dependent on the CPRNG.  That way you get a module build by default, but you can
change it to y manually during config and still satisfy the dependency, and if
you select N it disables FIPS as well.  I rather like that better than making
FIPS a tristate.  I just tested it out here and it seems to work well.  Let me
know what you think
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4e4ed83b
  55. 13 8月, 2009 1 次提交
  57. 06 8月, 2009 2 次提交
  59. 21 6月, 2009 1 次提交
  61. 19 6月, 2009 1 次提交
  63. 02 6月, 2009 2 次提交
    • H
      crypto: aes-ni - Add support for more modes · 2cf4ac8b
      由 Huang Ying 提交于 
      Because kernel_fpu_begin() and kernel_fpu_end() operations are too
slow, the performance gain of general mode implementation + aes-aesni
is almost all compensated.

The AES-NI support for more modes are implemented as follow:

- Add a new AES algorithm implementation named __aes-aesni without
  kernel_fpu_begin/end()

- Use fpu(<mode>(AES)) to provide kenrel_fpu_begin/end() invoking

- Add <mode>(AES) ablkcipher, which uses cryptd(fpu(<mode>(AES))) to
  defer cryption to cryptd context in soft_irq context.

Now the ctr, lrw, pcbc and xts support are added.

Performance testing based on dm-crypt shows that cryption time can be
reduced to 50% of general mode implementation + aes-aesni implementation.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2cf4ac8b
    • H
      crypto: fpu - Add template for blkcipher touching FPU · 150c7e85
      由 Huang Ying 提交于 
      Blkcipher touching FPU need to be enclosed by kernel_fpu_begin() and
kernel_fpu_end(). If they are invoked in cipher algorithm
implementation, they will be invoked for each block, so that
performance will be hurt, because they are "slow" operations. This
patch implements "fpu" template, which makes these operations to be
invoked for each request.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      150c7e85