1. 29 Apr, 2019 30 commits
  2. 26 Apr, 2019 7 commits
  3. 25 Apr, 2019 3 commits
    • Martin Schwidefsky's avatar
      s390: report new CPU capabilities · a8fd6168
      Martin Schwidefsky authored
      Add hardware capability bits and features tags to /proc/cpuinfo
      for 4 new CPU features:
        "Vector-Enhancements Facility 2" (tag "vxe2", hwcap 2^15)
        "Vector-Packed-Decimal-Enhancement Facility" (tag "vxp", hwcap 2^16)
        "Enhanced-Sort Facility" (tag "sort", hwcap 2^17)
        "Deflate-Conversion Facility" (tag "dflt", hwcap 2^18)
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      a8fd6168
    • Harald Freudenberger's avatar
      s390/crypto: use TRNG for seeding/reseeding · 769f020b
      Harald Freudenberger authored
      With the z14 machine there came also a CPACF hardware extension
      which provides a True Random Number Generator. This TRNG can
      be accessed with a new subfunction code within the CPACF prno
      instruction and provides random data with very high entropy.
      
      So if there is a TRNG available, let's use it for initial seeding
      and reseeding instead of the current implementation which tries
      to generate entropy based on stckf (store clock fast) jitters.
      
      For details about the amount of data needed and pulled for
      seeding and reseeding there can be explaining comments in the
      code found.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      769f020b
    • Harald Freudenberger's avatar
      s390/crypto: rework generate_entropy function for pseudo random dd · 23d1aee9
      Harald Freudenberger authored
      Here is a rework of the generate_entropy function of the pseudo random
      device driver exploiting the prno CPACF instruction.
      
      George Spelvin pointed out some issues with the existing
      implementation. One point was, that the buffer used to store the stckf
      values is 2 pages which are initially filled with get_random_bytes()
      for each 64 byte junk produced by the function. Another point was that
      the stckf values only carry entropy in the LSB and thus a buffer of
      2 pages is not really needed. Then there was a comment about the use
      of the kimd cpacf function without proper initialization.
      
      The rework addresses these points and now one page is used and only
      one half of this is filled with get_random_bytes() on each chunk of 64
      bytes requested data. The other half of the page is filled with stckf
      values exored into with an overlap of 4 bytes. This can be done due to
      the fact that only the lower 4 bytes carry entropy we need.  For more
      details about the algorithm used, see the header of the function.
      
      The generate_entropy() function now uses the cpacf function klmd with
      proper initialization of the parameter block to perform the sha512
      hash.
      
      George also pointed out some issues with the internal buffers used for
      seeding and reads. These buffers are now zeroed with memzero_implicit
      after use.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reported-by: default avatarGeorge Spelvin <lkml@sdf.org>
      Suggested-by: default avatarGeorge Spelvin <lkml@sdf.org>
      Reviewed-by: default avatarPatrick Steuer <steuer@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      23d1aee9