Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 6月, 2017 2 次提交
  3. 21 4月, 2017 1 次提交
    • K
      crypto: exynos - Add new Exynos RNG driver · c46ea13f
      由 Krzysztof Kozlowski 提交于 
      Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
This is a driver for pseudo random number generator block which on
Exynos4 chipsets must be seeded with some value.  On newer Exynos5420
chipsets it might seed itself from true random number generator block
but this is not implemented yet.

New driver is a complete rework to use the crypto ALGAPI instead of
hw_random API.  Rationale for the change:
1. hw_random interface is for true RNG devices.
2. The old driver was seeding itself with jiffies which is not a
   reliable source for randomness.
3. Device generates five random 32-bit numbers in each pass but old
   driver was returning only one 32-bit number thus its performance was
   reduced.

Compatibility with DeviceTree bindings is preserved.

New driver does not use runtime power management but manually enables
and disables the clock when needed.  This is preferred approach because
using runtime PM just to toggle clock is huge overhead.

Another difference is reseeding itself with generated random data
periodically and during resuming from system suspend (previously driver
was re-seeding itself again with jiffies).
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NStephan Müller <smueller@chronox.de>
Reviewed-by: NPrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c46ea13f
  5. 05 4月, 2017 1 次提交
  7. 09 3月, 2017 1 次提交
  9. 27 2月, 2017 2 次提交
  11. 24 2月, 2017 1 次提交
    • M
      s390/crypt: Add protected key AES module · 27937843
      由 Martin Schwidefsky 提交于 
      This patch introduces a new in-kernel-crypto blockcipher
called 'paes' which implements AES with protected keys.
The paes blockcipher can be used similar to the aes
blockcipher but uses secure key material to derive the
working protected key and so offers an encryption
implementation where never a clear key value is exposed
in memory.

The paes module is only available for the s390 platform
providing a minimal hardware support of CPACF enabled
with at least MSA level 3. Upon module initialization
these requirements are checked.

Includes additional contribution from Harald Freudenberger.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      27937843
  13. 23 2月, 2017 2 次提交
  15. 11 2月, 2017 3 次提交
  17. 03 2月, 2017 1 次提交
    • C
      crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes · 89a82ef8
      由 Cyrille Pitchen 提交于 
      This patchs allows to combine the AES and SHA hardware accelerators on
some Atmel SoCs. Doing so, AES blocks are only written to/read from the
AES hardware. Those blocks are also transferred from the AES to the SHA
accelerator internally, without additionnal accesses to the system busses.

Hence, the AES and SHA accelerators work in parallel to process all the
data blocks, instead of serializing the process by (de)crypting those
blocks first then authenticating them after like the generic
crypto/authenc.c driver does.

Of course, both the AES and SHA hardware accelerators need to be available
before we can start to process the data blocks. Hence we use their crypto
request queue to synchronize both drivers.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      89a82ef8
  19. 23 1月, 2017 1 次提交
  21. 13 1月, 2017 2 次提交
  23. 27 12月, 2016 1 次提交
  25. 16 12月, 2016 1 次提交
    • G
      crypto: add virtio-crypto driver · dbaf0624
      由 Gonglei 提交于 
      This patch introduces virtio-crypto driver for Linux Kernel.

The virtio crypto device is a virtual cryptography device
as well as a kind of virtual hardware accelerator for
virtual machines. The encryption anddecryption requests
are placed in the data queue and are ultimately handled by
thebackend crypto accelerators. The second queue is the
control queue used to create or destroy sessions for
symmetric algorithms and will control some advanced features
in the future. The virtio crypto device provides the following
cryptoservices: CIPHER, MAC, HASH, and AEAD.

For more information about virtio-crypto device, please see:
  http://qemu-project.org/Features/VirtioCrypto

CC: Michael S. Tsirkin <mst@redhat.com>
CC: Cornelia Huck <cornelia.huck@de.ibm.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: Halil Pasic <pasic@linux.vnet.ibm.com>
CC: David S. Miller <davem@davemloft.net>
CC: Zeng Xin <xin.zeng@intel.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      dbaf0624
  27. 13 9月, 2016 1 次提交
  29. 19 8月, 2016 1 次提交
  31. 15 6月, 2016 1 次提交
  33. 03 5月, 2016 1 次提交
  35. 20 4月, 2016 1 次提交
  37. 15 4月, 2016 1 次提交
  39. 05 4月, 2016 2 次提交
  41. 28 2月, 2016 1 次提交
  43. 06 2月, 2016 1 次提交
  45. 01 2月, 2016 1 次提交
  47. 18 1月, 2016 1 次提交
  49. 23 12月, 2015 1 次提交
  51. 22 12月, 2015 1 次提交
  53. 27 11月, 2015 1 次提交
  55. 23 11月, 2015 1 次提交
    • A
      crypto: atmel: fix bogus select · 56b85c9d
      由 Arnd Bergmann 提交于 
      The Atmel at91 crypto driver unconditionally selects AT_HDMAC,
which results in a Kconfig warning if that driver is not enabled:

warning: (CRYPTO_DEV_ATMEL_AES) selects AT_HDMAC which has unmet direct dependencies (DMADEVICES && ARCH_AT91)

The crypto driver itself does not actually have a dependency
on a particular dma engine, other than this being the one that
is used in at91.

Removing the 'select' gets rid of the warning, but can cause
the driver to be unusable if the HDMAC is not enabled at the
same time. To work around that, this patch clarifies the runtime
dependency to be 'AT_HDMAC || AT_XDMAC', but adds an alternative
for COMPILE_TEST, which lets the driver get build on all systems.

The ARCH_AT91 dependency is implied by AT_XDMAC || AT_HDMAC now
and no longer needs to be listed separately.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      56b85c9d
  57. 14 10月, 2015 1 次提交
    • A
      crypto: mxs-dcp - mxs-dcp is an stmp device · dc97fa02
      由 Arnd Bergmann 提交于 
      The mxs-dcp driver relies on the stmp_reset_block() helper function, which
is provided by CONFIG_STMP_DEVICE. This symbol is always set on MXS,
but the driver can now also be built for MXC (i.MX6), which results
in a built error if no other driver selects STMP_DEVICE:

drivers/built-in.o: In function `mxs_dcp_probe':
vf610-ocotp.c:(.text+0x3df302): undefined reference to `stmp_reset_block'

This adds the 'select', like all other stmp drivers have it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: a2712e6c ("crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL")
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dc97fa02
  59. 08 10月, 2015 1 次提交
  61. 21 9月, 2015 1 次提交
  63. 10 9月, 2015 1 次提交
  65. 20 7月, 2015 1 次提交