Skip to content

L
linux
Switch branch/tag
  1. 29 Apr, 2019 28 commits
  3. 26 Apr, 2019 7 commits
  5. 25 Apr, 2019 4 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
    • Martin Schwidefsky's avatar
      Merge tag 'vfio-ccw-20190425' of... · 5513bc8e
      Martin Schwidefsky authored 
      Merge tag 'vfio-ccw-20190425' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features

Pull vfio-ccw from Cornelia Huck with the following changes:

 - support for sending halt/clear requests to the device

 - various bug fixes
      5513bc8e
  7. 24 Apr, 2019 1 commit
    • Farhan Ali's avatar
      vfio-ccw: Prevent quiesce function going into an infinite loop · d1ffa760
      Farhan Ali authored 
      The quiesce function calls cio_cancel_halt_clear() and if we
get an -EBUSY we go into a loop where we:
	- wait for any interrupts
	- flush all I/O in the workqueue
	- retry cio_cancel_halt_clear

During the period where we are waiting for interrupts or
flushing all I/O, the channel subsystem could have completed
a halt/clear action and turned off the corresponding activity
control bits in the subchannel status word. This means the next
time we call cio_cancel_halt_clear(), we will again start by
calling cancel subchannel and so we can be stuck between calling
cancel and halt forever.

Rather than calling cio_cancel_halt_clear() immediately after
waiting, let's try to disable the subchannel. If we succeed in
disabling the subchannel then we know nothing else can happen
with the device.
Suggested-by: default avatarEric Farman <farman@linux.ibm.com>
Signed-off-by: default avatarFarhan Ali <alifm@linux.ibm.com>
Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com>
Reviewed-by: default avatarEric Farman <farman@linux.ibm.com>
Acked-by: default avatarHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      d1ffa760
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7