An error occurred fetching the project authors.
  1. 09 Nov, 2018 3 commits
  2. 08 Oct, 2018 1 commit
    • Harald Freudenberger's avatar
      s390/zcrypt: multiple zcrypt device nodes support · 00fab235
      Harald Freudenberger authored
      This patch is an extension to the zcrypt device driver to provide,
      support and maintain multiple zcrypt device nodes. The individual
      zcrypt device nodes can be restricted in terms of crypto cards,
      domains and available ioctls. Such a device node can be used as a
      base for container solutions like docker to control and restrict
      the access to crypto resources.
      
      The handling is done with a new sysfs subdir /sys/class/zcrypt.
      Echoing a name (or an empty sting) into the attribute "create" creates
      a new zcrypt device node. In /sys/class/zcrypt a new link will appear
      which points to the sysfs device tree of this new device. The
      attribute files "ioctlmask", "apmask" and "aqmask" in this directory
      are used to customize this new zcrypt device node instance. Finally
      the zcrypt device node can be destroyed by echoing the name into
      /sys/class/zcrypt/destroy. The internal structs holding the device
      info are reference counted - so a destroy will not hard remove a
      device but only marks it as removable when the reference counter drops
      to zero.
      
      The mask values are bitmaps in big endian order starting with bit 0.
      So adapter number 0 is the leftmost bit, mask is 0x8000...  The sysfs
      attributes accept 2 different formats:
      * Absolute hex string starting with 0x like "0x12345678" does set
        the mask starting from left to right. If the given string is shorter
        than the mask it is padded with 0s on the right. If the string is
        longer than the mask an error comes back (EINVAL).
      * Relative format - a concatenation (done with ',') of the
        terms +<bitnr>[-<bitnr>] or -<bitnr>[-<bitnr>]. <bitnr> may be any
        valid number (hex, decimal or octal) in the range 0...255. Here are
        some examples:
          "+0-15,+32,-128,-0xFF"
          "-0-255,+1-16,+0x128"
          "+1,+2,+3,+4,-5,-7-10"
      
      A simple usage examples:
      
        # create new zcrypt device 'my_zcrypt':
        echo "my_zcrypt" >/sys/class/zcrypt/create
        # go into the device dir of this new device
        echo "my_zcrypt" >create
        cd my_zcrypt/
        ls -l
        total 0
        -rw-r--r-- 1 root root 4096 Jul 20 15:23 apmask
        -rw-r--r-- 1 root root 4096 Jul 20 15:23 aqmask
        -r--r--r-- 1 root root 4096 Jul 20 15:23 dev
        -rw-r--r-- 1 root root 4096 Jul 20 15:23 ioctlmask
        lrwxrwxrwx 1 root root    0 Jul 20 15:23 subsystem -> ../../../../class/zcrypt
        ...
        # customize this zcrypt node clone
        # enable only adapter 0 and 2
        echo "0xa0" >apmask
        # enable only domain 6
        echo "+6" >aqmask
        # enable all 256 ioctls
        echo "+0-255" >ioctls
        # now the /dev/my_zcrypt may be used
        # finally destroy it
        echo "my_zcrypt" >/sys/class/zcrypt/destroy
      
      Please note that a very similar 'filtering behavior' also applies to
      the parent z90crypt device. The two mask attributes apmask and aqmask
      in /sys/bus/ap act the very same for the z90crypt device node. However
      the implementation here is totally different as the ap bus acts on
      bind/unbind of queue devices and associated drivers but the effect is
      still the same. So there are two filters active for each additional
      zcrypt device node: The adapter/domain needs to be enabled on the ap
      bus level and it needs to be active on the zcrypt device node level.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      00fab235
  3. 03 Aug, 2018 1 commit
  4. 27 Jul, 2018 1 commit
  5. 08 Jul, 2018 2 commits
  6. 26 May, 2018 1 commit
  7. 28 Apr, 2018 2 commits
  8. 23 Mar, 2018 1 commit
  9. 02 Mar, 2018 1 commit
  10. 15 Feb, 2018 1 commit
  11. 25 Jan, 2018 1 commit
  12. 03 Nov, 2017 2 commits
  13. 12 Oct, 2017 1 commit
  14. 22 Aug, 2017 1 commit
  15. 18 Jul, 2017 4 commits
  16. 12 Jun, 2017 1 commit
  17. 10 Jun, 2017 4 commits
  18. 21 Apr, 2017 1 commit
    • Krzysztof Kozlowski's avatar
      crypto: exynos - Add new Exynos RNG driver · c46ea13f
      Krzysztof Kozlowski authored
      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: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Reviewed-by: default avatarStephan Müller <smueller@chronox.de>
      Reviewed-by: default avatarPrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
      Reviewed-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c46ea13f
  19. 05 Apr, 2017 1 commit
  20. 09 Mar, 2017 1 commit
  21. 27 Feb, 2017 2 commits
  22. 24 Feb, 2017 1 commit
    • Martin Schwidefsky's avatar
      s390/crypt: Add protected key AES module · 27937843
      Martin Schwidefsky authored
      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: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      27937843
  23. 23 Feb, 2017 2 commits
  24. 11 Feb, 2017 3 commits
  25. 03 Feb, 2017 1 commit
    • Cyrille Pitchen's avatar
      crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes · 89a82ef8
      Cyrille Pitchen authored
      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: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      89a82ef8