1. 26 Sep, 2018 1 commit
    • Corey Minyard's avatar
      ipmi: Fix I2C client removal in the SSIF driver · 888e989a
      Corey Minyard authored
      commit 0745dde6 upstream.
      
      The SSIF driver was removing any client that came in through the
      platform interface, but it should only remove clients that it
      added.  On a failure in the probe function, this could result
      in the following oops when the driver is removed and the
      client gets unregistered twice:
      
       CPU: 107 PID: 30266 Comm: rmmod Not tainted 4.18.0+ #80
       Hardware name: Cavium Inc. Saber/Saber, BIOS Cavium reference firmware version 7.0 08/04/2018
       pstate: 60400009 (nZCv daif +PAN -UAO)
       pc : kernfs_find_ns+0x28/0x120
       lr : kernfs_find_and_get_ns+0x40/0x60
       sp : ffff00002310fb50
       x29: ffff00002310fb50 x28: ffff800a8240f800
       x27: 0000000000000000 x26: 0000000000000000
       x25: 0000000056000000 x24: ffff000009073000
       x23: ffff000008998b38 x22: 0000000000000000
       x21: ffff800ed86de820 x20: 0000000000000000
       x19: ffff00000913a1d8 x18: 0000000000000000
       x17: 0000000000000000 x16: 0000000000000000
       x15: 0000000000000000 x14: 5300737265766972
       x13: 643d4d4554535953 x12: 0000000000000030
       x11: 0000000000000030 x10: 0101010101010101
       x9 : ffff800ea06cc3f9 x8 : 0000000000000000
       x7 : 0000000000000141 x6 : ffff000009073000
       x5 : ffff800adb706b00 x4 : 0000000000000000
       x3 : 00000000ffffffff x2 : 0000000000000000
       x1 : ffff000008998b38 x0 : ffff000008356760
       Process rmmod (pid: 30266, stack limit = 0x00000000e218418d)
       Call trace:
        kernfs_find_ns+0x28/0x120
        kernfs_find_and_get_ns+0x40/0x60
        sysfs_unmerge_group+0x2c/0x6c
        dpm_sysfs_remove+0x34/0x70
        device_del+0x58/0x30c
        device_unregister+0x30/0x7c
        i2c_unregister_device+0x84/0x90 [i2c_core]
        ssif_platform_remove+0x38/0x98 [ipmi_ssif]
        platform_drv_remove+0x2c/0x6c
        device_release_driver_internal+0x168/0x1f8
        driver_detach+0x50/0xbc
        bus_remove_driver+0x74/0xe8
        driver_unregister+0x34/0x5c
        platform_driver_unregister+0x20/0x2c
        cleanup_ipmi_ssif+0x50/0xd82c [ipmi_ssif]
        __arm64_sys_delete_module+0x1b4/0x220
        el0_svc_handler+0x104/0x160
        el0_svc+0x8/0xc
       Code: aa1e03e0 aa0203f6 aa0103f7 d503201f (7940e280)
       ---[ end trace 09f0e34cce8e2d8c ]---
       Kernel panic - not syncing: Fatal exception
       SMP: stopping secondary CPUs
       Kernel Offset: disabled
       CPU features: 0x23800c38
      
      So track the clients that the SSIF driver adds and only remove
      those.
      Reported-by: default avatarGeorge Cherian <george.cherian@cavium.com>
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Tested-by: default avatarGeorge Cherian <george.cherian@cavium.com>
      Cc: <stable@vger.kernel.org> # 4.14.x
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      888e989a
  2. 19 Sep, 2018 3 commits
  3. 05 Sep, 2018 1 commit
  4. 03 Aug, 2018 1 commit
    • Theodore Ts'o's avatar
      random: mix rdrand with entropy sent in from userspace · af41fd04
      Theodore Ts'o authored
      commit 81e69df3 upstream.
      
      Fedora has integrated the jitter entropy daemon to work around slow
      boot problems, especially on VM's that don't support virtio-rng:
      
          https://bugzilla.redhat.com/show_bug.cgi?id=1572944
      
      It's understandable why they did this, but the Jitter entropy daemon
      works fundamentally on the principle: "the CPU microarchitecture is
      **so** complicated and we can't figure it out, so it *must* be
      random".  Yes, it uses statistical tests to "prove" it is secure, but
      AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
      flying colors.
      
      So if RDRAND is available, mix it into entropy submitted from
      userspace.  It can't hurt, and if you believe the NSA has backdoored
      RDRAND, then they probably have enough details about the Intel
      microarchitecture that they can reverse engineer how the Jitter
      entropy daemon affects the microarchitecture, and attack its output
      stream.  And if RDRAND is in fact an honest DRNG, it will immeasurably
      improve on what the Jitter entropy daemon might produce.
      
      This also provides some protection against someone who is able to read
      or set the entropy seed file.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af41fd04
  5. 03 Jul, 2018 3 commits
  6. 20 Jun, 2018 1 commit
  7. 30 May, 2018 2 commits
  8. 01 May, 2018 8 commits
  9. 29 Apr, 2018 3 commits
  10. 26 Apr, 2018 1 commit
  11. 24 Apr, 2018 6 commits
  12. 12 Apr, 2018 1 commit
  13. 08 Apr, 2018 1 commit
  14. 24 Mar, 2018 1 commit
  15. 19 Mar, 2018 1 commit
  16. 15 Mar, 2018 5 commits
  17. 09 Mar, 2018 1 commit