1. 20 9月, 2019 1 次提交
    • L
      hwrng: core - don't wait on add_early_randomness() · 78887832
      Laurent Vivier 提交于
      add_early_randomness() is called by hwrng_register() when the
      hardware is added. If this hardware and its module are present
      at boot, and if there is no data available the boot hangs until
      data are available and can't be interrupted.
      
      For instance, in the case of virtio-rng, in some cases the host can be
      not able to provide enough entropy for all the guests.
      
      We can have two easy ways to reproduce the problem but they rely on
      misconfiguration of the hypervisor or the egd daemon:
      
      - if virtio-rng device is configured to connect to the egd daemon of the
      host but when the virtio-rng driver asks for data the daemon is not
      connected,
      
      - if virtio-rng device is configured to connect to the egd daemon of the
      host but the egd daemon doesn't provide data.
      
      The guest kernel will hang at boot until the virtio-rng driver provides
      enough data.
      
      To avoid that, call rng_get_data() in non-blocking mode (wait=0)
      from add_early_randomness().
      Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
      Fixes: d9e79726 ("hwrng: add randomness to system from rng...")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      78887832
  2. 05 9月, 2019 1 次提交
    • D
      hwrng: timeriomem - relax check on memory resource size · 2a4bfd02
      Daniel Mack 提交于
      The timeriomem_rng driver only accesses the first 4 bytes of the given
      memory area and currently, it also forces that memory resource to be
      exactly 4 bytes in size.
      
      This, however, is problematic when used with device-trees that are
      generated from things like FPGA toolchains, where the minimum size
      of an exposed memory block may be something like 4k.
      
      Hence, let's only check for what's needed for the driver to operate
      properly; namely that we have enough memory available to read the
      random data from.
      Signed-off-by: NDaniel Mack <daniel@zonque.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2a4bfd02
  3. 15 8月, 2019 1 次提交
    • S
      hwrng: core - Freeze khwrng thread during suspend · 03a3bb7a
      Stephen Boyd 提交于
      The hwrng_fill() function can run while devices are suspending and
      resuming. If the hwrng is behind a bus such as i2c or SPI and that bus
      is suspended, the hwrng may hang the bus while attempting to add some
      randomness. It's been observed on ChromeOS devices with suspend-to-idle
      (s2idle) and an i2c based hwrng that this kthread may run and ask the
      hwrng device for randomness before the i2c bus has been resumed.
      
      Let's make this kthread freezable so that we don't try to touch the
      hwrng during suspend/resume. This ensures that we can't cause the hwrng
      backing driver to get into a bad state because the device is guaranteed
      to be resumed before the hwrng kthread is thawed.
      
      Cc: Andrey Pronin <apronin@chromium.org>
      Cc: Duncan Laurie <dlaurie@chromium.org>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Guenter Roeck <groeck@chromium.org>
      Cc: Alexander Steffen <Alexander.Steffen@infineon.com>
      Signed-off-by: NStephen Boyd <swboyd@chromium.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      03a3bb7a
  4. 08 8月, 2019 1 次提交
  5. 02 8月, 2019 1 次提交
  6. 27 7月, 2019 2 次提交
  7. 15 7月, 2019 1 次提交
  8. 20 6月, 2019 1 次提交
  9. 19 6月, 2019 1 次提交
  10. 05 6月, 2019 3 次提交
  11. 31 5月, 2019 4 次提交
  12. 30 5月, 2019 1 次提交
  13. 24 5月, 2019 2 次提交
  14. 21 5月, 2019 3 次提交
  15. 15 4月, 2019 2 次提交
  16. 22 3月, 2019 1 次提交
    • R
      hwrng: omap - Set default quality · 62f95ae8
      Rouven Czerwinski 提交于
      Newer combinations of the glibc, kernel and openssh can result in long initial
      startup times on OMAP devices:
      
      [    6.671425] systemd-rc-once[102]: Creating ED25519 key; this may take some time ...
      [  142.652491] systemd-rc-once[102]: Creating ED25519 key; done.
      
      due to the blocking getrandom(2) system call:
      
      [  142.610335] random: crng init done
      
      Set the quality level for the omap hwrng driver allowing the kernel to use the
      hwrng as an entropy source at boot.
      Signed-off-by: NRouven Czerwinski <r.czerwinski@pengutronix.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      62f95ae8
  17. 28 2月, 2019 1 次提交
  18. 21 2月, 2019 2 次提交
  19. 20 2月, 2019 1 次提交
  20. 01 2月, 2019 1 次提交
  21. 25 1月, 2019 1 次提交
    • D
      hwrng: virtio - Avoid repeated init of completion · aef027db
      David Tolnay 提交于
      The virtio-rng driver uses a completion called have_data to wait for a
      virtio read to be fulfilled by the hypervisor. The completion is reset
      before placing a buffer on the virtio queue and completed by the virtio
      callback once data has been written into the buffer.
      
      Prior to this commit, the driver called init_completion on this
      completion both during probe as well as when registering virtio buffers
      as part of a hwrng read operation. The second of these init_completion
      calls should instead be reinit_completion because the have_data
      completion has already been inited by probe. As described in
      Documentation/scheduler/completion.txt, "Calling init_completion() twice
      on the same completion object is most likely a bug".
      
      This bug was present in the initial implementation of virtio-rng in
      f7f510ec ("virtio: An entropy device, as suggested by hpa"). Back
      then the have_data completion was a single static completion rather than
      a member of one of potentially multiple virtrng_info structs as
      implemented later by 08e53fbd ("virtio-rng: support multiple
      virtio-rng devices"). The original driver incorrectly used
      init_completion rather than INIT_COMPLETION to reset have_data during
      read.
      
      Tested by running `head -c48 /dev/random | hexdump` within crosvm, the
      Chrome OS virtual machine monitor, and confirming that the virtio-rng
      driver successfully produces random bytes from the host.
      Signed-off-by: NDavid Tolnay <dtolnay@gmail.com>
      Tested-by: NDavid Tolnay <dtolnay@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      aef027db
  22. 16 11月, 2018 1 次提交
  23. 05 10月, 2018 1 次提交
    • M
      hwrng: core - document the quality field · fae29f13
      Michael S. Tsirkin 提交于
      quality field is currently documented as being 'per mill'.  In fact the
      math involved is:
      
                      add_hwgenerator_randomness((void *)rng_fillbuf, rc,
                                                 rc * current_quality * 8 >> 10);
      
      thus the actual definition is "bits of entropy per 1024 bits of input".
      
      The current documentation seems to have confused multiple people
      in the past, let's fix the documentation to match code.
      
      An alternative is to change core to match driver expectations, replacing
      	rc * current_quality * 8 >> 10
      with
      	rc * current_quality / 1000
      but that has performance costs, so probably isn't a good option.
      
      Fixes: 0f734e6e ("hwrng: add per-device entropy derating")
      Reported-by: N"Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fae29f13
  24. 27 7月, 2018 1 次提交
  25. 07 7月, 2018 1 次提交
    • R
      headers: separate linux/mod_devicetable.h from linux/platform_device.h · ac316725
      Randy Dunlap 提交于
      At over 4000 #includes, <linux/platform_device.h> is the 9th most
      #included header file in the Linux kernel.  It does not need
      <linux/mod_devicetable.h>, so drop that header and explicitly add
      <linux/mod_devicetable.h> to source files that need it.
      
         4146 #include <linux/platform_device.h>
      
      After this patch, there are 225 files that use <linux/mod_devicetable.h>,
      for a reduction of around 3900 times that <linux/mod_devicetable.h>
      does not have to be read & parsed.
      
          225 #include <linux/mod_devicetable.h>
      
      This patch was build-tested on 20 different arch-es.
      
      It also makes these drivers SubmitChecklist#1 compliant.
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Reported-by: kbuild test robot <lkp@intel.com> # drivers/media/platform/vimc/
      Reported-by: kbuild test robot <lkp@intel.com> # drivers/pinctrl/pinctrl-u300.c
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac316725
  26. 15 6月, 2018 1 次提交
    • M
      hwrng: core - Always drop the RNG in hwrng_unregister() · 837bf7cc
      Michael Büsch 提交于
      enable_best_rng() is used in hwrng_unregister() to switch away from the
      currently active RNG, if that is the one currently being removed.
      However enable_best_rng() might fail, if the next RNG's init routine
      fails. In that case enable_best_rng() will return an error code and
      the currently active RNG will remain active.
      After unregistering this might lead to crashes due to use-after-free.
      
      Fix this by dropping the currently active RNG, if enable_best_rng()
      failed. This will result in no RNG to be active, if the next-best
      one failed to initialize.
      
      This problem was introduced by 142a27f0
      
      Fixes: 142a27f0 ("hwrng: core - Reset user selected rng by...")
      Reported-by: NWirz <spam@lukas-wirz.de>
      Tested-by: NWirz <spam@lukas-wirz.de>
      Signed-off-by: NMichael Büsch <m@bues.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      837bf7cc
  27. 19 5月, 2018 1 次提交
  28. 05 5月, 2018 2 次提交