commit f051383ef03bde49ca992f297ec80757a702e774
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jun 25 11:46:46 2022 +0200

    Linux 4.14.285
    
    Link: https://lore.kernel.org/r/20220623164343.132308638@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a2659e2e940b405895c4e19a683aa7fa846a785
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon May 2 10:46:14 2022 +0200

    tcp: drop the hash_32() part from the index calculation
    
    commit e8161345ddbb66e449abde10d2fdce93f867eba9 upstream.
    
    In commit 190cc82489f4 ("tcp: change source port randomizarion at
    connect() time"), the table_perturb[] array was introduced and an
    index was taken from the port_offset via hash_32(). But it turns
    out that hash_32() performs a multiplication while the input here
    comes from the output of SipHash in secure_seq, that is well
    distributed enough to avoid the need for yet another hash.
    
    Suggested-by: Amit Klein <aksecurity@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9044e70fadec49482c3cb3c2f49e81825796ea6d
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon May 2 10:46:13 2022 +0200

    tcp: increase source port perturb table to 2^16
    
    commit 4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5 upstream.
    
    Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately
    identify a client by forcing it to emit only 40 times more connections
    than there are entries in the table_perturb[] table. The previous two
    improvements consisting in resalting the secret every 10s and adding
    randomness to each port selection only slightly improved the situation,
    and the current value of 2^8 was too small as it's not very difficult
    to make a client emit 10k connections in less than 10 seconds.
    
    Thus we're increasing the perturb table from 2^8 to 2^16 so that the
    same precision now requires 2.6M connections, which is more difficult in
    this time frame and harder to hide as a background activity. The impact
    is that the table now uses 256 kB instead of 1 kB, which could mostly
    affect devices making frequent outgoing connections. However such
    components usually target a small set of destinations (load balancers,
    database clients, perf assessment tools), and in practice only a few
    entries will be visited, like before.
    
    A live test at 1 million connections per second showed no performance
    difference from the previous value.
    
    Reported-by: Moshe Kol <moshe.kol@mail.huji.ac.il>
    Reported-by: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
    Reported-by: Amit Klein <aksecurity@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c251cc4f664a4ae922c9431f2eb4559cb3c737a
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon May 2 10:46:12 2022 +0200

    tcp: dynamically allocate the perturb table used by source ports
    
    commit e9261476184be1abd486c9434164b2acbe0ed6c2 upstream.
    
    We'll need to further increase the size of this table and it's likely
    that at some point its size will not be suitable anymore for a static
    table. Let's allocate it on boot from inet_hashinfo2_init(), which is
    called from tcp_init().
    
    Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
    Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
    Cc: Amit Klein <aksecurity@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [bwh: Backported to 4.14:
     - There is no inet_hashinfo2_init(), so allocate the table in
       inet_hashinfo_init() when called by TCP
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43995cd1fec2da248ff60be3baba8ed730f03a66
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon May 2 10:46:11 2022 +0200

    tcp: add small random increments to the source port
    
    commit ca7af0402550f9a0b3316d5f1c30904e42ed257d upstream.
    
    Here we're randomly adding between 0 and 7 random increments to the
    selected source port in order to add some noise in the source port
    selection that will make the next port less predictable.
    
    With the default port range of 32768-60999 this means a worst case
    reuse scenario of 14116/8=1764 connections between two consecutive
    uses of the same port, with an average of 14116/4.5=3137. This code
    was stressed at more than 800000 connections per second to a fixed
    target with all connections closed by the client using RSTs (worst
    condition) and only 2 connections failed among 13 billion, despite
    the hash being reseeded every 10 seconds, indicating a perfectly
    safe situation.
    
    Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
    Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
    Cc: Amit Klein <aksecurity@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1e99d0a7dbb313c0059d3b4c9d834759541b3ac
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon May 2 10:46:09 2022 +0200

    tcp: use different parts of the port_offset for index and offset
    
    commit 9e9b70ae923baf2b5e8a0ea4fd0c8451801ac526 upstream.
    
    Amit Klein suggests that we use different parts of port_offset for the
    table's index and the port offset so that there is no direct relation
    between them.
    
    Cc: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
    Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
    Cc: Amit Klein <aksecurity@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76d3468b1af6622651f89401634bff6e40da18c1
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Feb 9 11:20:28 2021 -0800

    tcp: add some entropy in __inet_hash_connect()
    
    commit c579bd1b4021c42ae247108f1e6f73dd3f08600c upstream.
    
    Even when implementing RFC 6056 3.3.4 (Algorithm 4: Double-Hash
    Port Selection Algorithm), a patient attacker could still be able
    to collect enough state from an otherwise idle host.
    
    Idea of this patch is to inject some noise, in the
    cases __inet_hash_connect() found a candidate in the first
    attempt.
    
    This noise should not significantly reduce the collision
    avoidance, and should be zero if connection table
    is already well used.
    
    Note that this is not implementing RFC 6056 3.3.5
    because we think Algorithm 5 could hurt typical
    workloads.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: David Dworken <ddworken@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4779af1ec4a6c88a7005c8aabe69f409cf926d58
Author: Colin Ian King <colin.king@intel.com>
Date:   Wed Jul 15 17:26:04 2020 +0100

    xprtrdma: fix incorrect header size calculations
    
    commit 912288442cb2f431bf3c8cb097a5de83bc6dbac1 upstream.
    
    Currently the header size calculations are using an assignment
    operator instead of a += operator when accumulating the header
    size leading to incorrect sizes.  Fix this by using the correct
    operator.
    
    Addresses-Coverity: ("Unused value")
    Fixes: 302d3deb2068 ("xprtrdma: Prevent inline overflow")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    [bwh: Backported to 4.14: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbc8656939748c8fe002d4b0cd28d9e6f318ac26
Author: Marian Postevca <posteuca@mutex.one>
Date:   Fri Jun 3 18:34:59 2022 +0300

    usb: gadget: u_ether: fix regression in setting fixed MAC address
    
    commit b337af3a4d6147000b7ca6b3438bf5c820849b37 upstream.
    
    In systemd systems setting a fixed MAC address through
    the "dev_addr" module argument fails systematically.
    When checking the MAC address after the interface is created
    it always has the same but different MAC address to the one
    supplied as argument.
    
    This is partially caused by systemd which by default will
    set an internally generated permanent MAC address for interfaces
    that are marked as having a randomly generated address.
    
    Commit 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in
    setting MAC address in setup phase") didn't take into account
    the fact that the interface must be marked as having a set
    MAC address when it's set as module argument.
    
    Fixed by marking the interface with NET_ADDR_SET when
    the "dev_addr" module argument is supplied.
    
    Fixes: 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase")
    Cc: stable@vger.kernel.org
    Signed-off-by: Marian Postevca <posteuca@mutex.one>
    Link: https://lore.kernel.org/r/20220603153459.32722-1-posteuca@mutex.one
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1de03ea11a01580b98f4569207dedf4005916fa3
Author: Christian Borntraeger <borntraeger@linux.ibm.com>
Date:   Mon May 30 11:27:06 2022 +0200

    s390/mm: use non-quiescing sske for KVM switch to keyed guest
    
    commit 3ae11dbcfac906a8c3a480e98660a823130dc16a upstream.
    
    The switch to a keyed guest does not require a classic sske as the other
    guest CPUs are not accessing the key before the switch is complete.
    By using the NQ SSKE things are faster especially with multiple guests.
    
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Suggested-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220530092706.11637-3-borntraeger@linux.ibm.com
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1819c764fe0f851942c2b3cf5dae516e7bbe69d8
Author: James Chapman <jchapman@katalix.com>
Date:   Fri Feb 23 17:45:46 2018 +0000

    l2tp: fix race in pppol2tp_release with session object destroy
    
    commit d02ba2a6110c530a32926af8ad441111774d2893 upstream.
    
    pppol2tp_release uses call_rcu to put the final ref on its socket. But
    the session object doesn't hold a ref on the session socket so may be
    freed while the pppol2tp_put_sk RCU callback is scheduled. Fix this by
    having the session hold a ref on its socket until the session is
    destroyed. It is this ref that is dropped via call_rcu.
    
    Sessions are also deleted via l2tp_tunnel_closeall. This must now also put
    the final ref via call_rcu. So move the call_rcu call site into
    pppol2tp_session_close so that this happens in both destroy paths. A
    common destroy path should really be implemented, perhaps with
    l2tp_tunnel_closeall calling l2tp_session_delete like pppol2tp_release
    does, but this will be looked at later.
    
    ODEBUG: activate active (active state 1) object type: rcu_head hint:           (null)
    WARNING: CPU: 3 PID: 13407 at lib/debugobjects.c:291 debug_print_object+0x166/0x220
    Modules linked in:
    CPU: 3 PID: 13407 Comm: syzbot_19c09769 Not tainted 4.16.0-rc2+ #38
    Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    RIP: 0010:debug_print_object+0x166/0x220
    RSP: 0018:ffff880013647a00 EFLAGS: 00010082
    RAX: dffffc0000000008 RBX: 0000000000000003 RCX: ffffffff814d3333
    RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88001a59f6d0
    RBP: ffff880013647a40 R08: 0000000000000000 R09: 0000000000000001
    R10: ffff8800136479a8 R11: 0000000000000000 R12: 0000000000000001
    R13: ffffffff86161420 R14: ffffffff85648b60 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff88001a580000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020e77000 CR3: 0000000006022000 CR4: 00000000000006e0
    Call Trace:
     debug_object_activate+0x38b/0x530
     ? debug_object_assert_init+0x3b0/0x3b0
     ? __mutex_unlock_slowpath+0x85/0x8b0
     ? pppol2tp_session_destruct+0x110/0x110
     __call_rcu.constprop.66+0x39/0x890
     ? __call_rcu.constprop.66+0x39/0x890
     call_rcu_sched+0x17/0x20
     pppol2tp_release+0x2c7/0x440
     ? fcntl_setlk+0xca0/0xca0
     ? sock_alloc_file+0x340/0x340
     sock_release+0x92/0x1e0
     sock_close+0x1b/0x20
     __fput+0x296/0x6e0
     ____fput+0x1a/0x20
     task_work_run+0x127/0x1a0
     do_exit+0x7f9/0x2ce0
     ? SYSC_connect+0x212/0x310
     ? mm_update_next_owner+0x690/0x690
     ? up_read+0x1f/0x40
     ? __do_page_fault+0x3c8/0xca0
     do_group_exit+0x10d/0x330
     ? do_group_exit+0x330/0x330
     SyS_exit_group+0x22/0x30
     do_syscall_64+0x1e0/0x730
     ? trace_hardirqs_off_thunk+0x1a/0x1c
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    RIP: 0033:0x7f362e471259
    RSP: 002b:00007ffe389abe08 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f362e471259
    RDX: 00007f362e471259 RSI: 000000000000002e RDI: 0000000000000000
    RBP: 00007ffe389abe30 R08: 0000000000000000 R09: 00007f362e944270
    R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000400b60
    R13: 00007ffe389abf50 R14: 0000000000000000 R15: 0000000000000000
    Code: 8d 3c dd a0 8f 64 85 48 89 fa 48 c1 ea 03 80 3c 02 00 75 7b 48 8b 14 dd a0 8f 64 85 4c 89 f6 48 c7 c7 20 85 64 85 e
    8 2a 55 14 ff <0f> 0b 83 05 ad 2a 68 04 01 48 83 c4 18 5b 41 5c 41 5d 41 5e 41
    
    Fixes: ee40fb2e1eb5b ("l2tp: protect sock pointer of struct pppol2tp_session with RCU")
    Signed-off-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 352dce3a2cbbea1f1b14062f5bbdccb36b3b4793
Author: James Chapman <jchapman@katalix.com>
Date:   Fri Feb 23 17:45:44 2018 +0000

    l2tp: don't use inet_shutdown on ppp session destroy
    
    commit 225eb26489d05c679a4c4197ffcb81c81e9dcaf4 upstream.
    
    Previously, if a ppp session was closed, we called inet_shutdown to mark
    the socket as unconnected such that userspace would get errors and
    then close the socket. This could race with userspace closing the
    socket. Instead, leave userspace to close the socket in its own time
    (our session will be detached anyway).
    
    BUG: KASAN: use-after-free in inet_shutdown+0x5d/0x1c0
    Read of size 4 at addr ffff880010ea3ac0 by task syzbot_347bd5ac/8296
    
    CPU: 3 PID: 8296 Comm: syzbot_347bd5ac Not tainted 4.16.0-rc1+ #91
    Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    Call Trace:
     dump_stack+0x101/0x157
     ? inet_shutdown+0x5d/0x1c0
     print_address_description+0x78/0x260
     ? inet_shutdown+0x5d/0x1c0
     kasan_report+0x240/0x360
     __asan_load4+0x78/0x80
     inet_shutdown+0x5d/0x1c0
     ? pppol2tp_show+0x80/0x80
     pppol2tp_session_close+0x68/0xb0
     l2tp_tunnel_closeall+0x199/0x210
     ? udp_v6_flush_pending_frames+0x90/0x90
     l2tp_udp_encap_destroy+0x6b/0xc0
     ? l2tp_tunnel_del_work+0x2e0/0x2e0
     udpv6_destroy_sock+0x8c/0x90
     sk_common_release+0x47/0x190
     udp_lib_close+0x15/0x20
     inet_release+0x85/0xd0
     inet6_release+0x43/0x60
     sock_release+0x53/0x100
     ? sock_alloc_file+0x260/0x260
     sock_close+0x1b/0x20
     __fput+0x19f/0x380
     ____fput+0x1a/0x20
     task_work_run+0xd2/0x110
     exit_to_usermode_loop+0x18d/0x190
     do_syscall_64+0x389/0x3b0
     entry_SYSCALL_64_after_hwframe+0x26/0x9b
    RIP: 0033:0x7fe240a45259
    RSP: 002b:00007fe241132df8 EFLAGS: 00000297 ORIG_RAX: 0000000000000003
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007fe240a45259
    RDX: 00007fe240a45259 RSI: 0000000000000000 RDI: 00000000000000a5
    RBP: 00007fe241132e20 R08: 00007fe241133700 R09: 0000000000000000
    R10: 00007fe241133700 R11: 0000000000000297 R12: 0000000000000000
    R13: 00007ffc49aff84f R14: 0000000000000000 R15: 00007fe241141040
    
    Allocated by task 8331:
     save_stack+0x43/0xd0
     kasan_kmalloc+0xad/0xe0
     kasan_slab_alloc+0x12/0x20
     kmem_cache_alloc+0x144/0x3e0
     sock_alloc_inode+0x22/0x130
     alloc_inode+0x3d/0xf0
     new_inode_pseudo+0x1c/0x90
     sock_alloc+0x30/0x110
     __sock_create+0xaa/0x4c0
     SyS_socket+0xbe/0x130
     do_syscall_64+0x128/0x3b0
     entry_SYSCALL_64_after_hwframe+0x26/0x9b
    
    Freed by task 8314:
     save_stack+0x43/0xd0
     __kasan_slab_free+0x11a/0x170
     kasan_slab_free+0xe/0x10
     kmem_cache_free+0x88/0x2b0
     sock_destroy_inode+0x49/0x50
     destroy_inode+0x77/0xb0
     evict+0x285/0x340
     iput+0x429/0x530
     dentry_unlink_inode+0x28c/0x2c0
     __dentry_kill+0x1e3/0x2f0
     dput.part.21+0x500/0x560
     dput+0x24/0x30
     __fput+0x2aa/0x380
     ____fput+0x1a/0x20
     task_work_run+0xd2/0x110
     exit_to_usermode_loop+0x18d/0x190
     do_syscall_64+0x389/0x3b0
     entry_SYSCALL_64_after_hwframe+0x26/0x9b
    
    Fixes: fd558d186df2c ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
    Signed-off-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f064b12ba4cadc88dea20aaa5f77c60ebb9f1239
Author: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Date:   Thu Apr 14 23:30:02 2022 -0300

    virtio-pci: Remove wrong address verification in vp_del_vqs()
    
    commit 7e415282b41bf0d15c6e0fe268f822d9b083f2f7 upstream.
    
    GCC 12 enhanced -Waddress when comparing array address to null [0],
    which warns:
    
        drivers/virtio/virtio_pci_common.c: In function ‘vp_del_vqs’:
        drivers/virtio/virtio_pci_common.c:257:29: warning: the comparison will always evaluate as ‘true’ for the pointer operand in ‘vp_dev->msix_affinity_masks + (sizetype)((long unsigned int)i * 256)’ must not be NULL [-Waddress]
          257 |                         if (vp_dev->msix_affinity_masks[i])
              |                             ^~~~~~
    
    In fact, the verification is comparing the result of a pointer
    arithmetic, the address "msix_affinity_masks + i", which will always
    evaluate to true.
    
    Under the hood, free_cpumask_var() calls kfree(), which is safe to pass
    NULL, not requiring non-null verification.  So remove the verification
    to make compiler happy (happy compiler, happy life).
    
    [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103
    
    Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
    Message-Id: <20220415023002.49805-1-muriloo@linux.ibm.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Christophe de Dinechin <dinechin@redhat.com>
    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c921328ac760bba780bdace41f4cd045f7f1405
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Wed Jun 1 17:27:17 2022 +0800

    ext4: add reserved GDT blocks check
    
    commit b55c3cd102a6f48b90e61c44f7f3dda8c290c694 upstream.
    
    We capture a NULL pointer issue when resizing a corrupt ext4 image which
    is freshly clear resize_inode feature (not run e2fsck). It could be
    simply reproduced by following steps. The problem is because of the
    resize_inode feature was cleared, and it will convert the filesystem to
    meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
    not reduced to zero, so could we mistakenly call reserve_backup_gdb()
    and passing an uninitialized resize_inode to it when adding new group
    descriptors.
    
     mkfs.ext4 /dev/sda 3G
     tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
     mount /dev/sda /mnt
     resize2fs /dev/sda 8G
    
     ========
     BUG: kernel NULL pointer dereference, address: 0000000000000028
     CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
     ...
     RIP: 0010:ext4_flex_group_add+0xe08/0x2570
     ...
     Call Trace:
      <TASK>
      ext4_resize_fs+0xbec/0x1660
      __ext4_ioctl+0x1749/0x24e0
      ext4_ioctl+0x12/0x20
      __x64_sys_ioctl+0xa6/0x110
      do_syscall_64+0x3b/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f2dd739617b
     ========
    
    The fix is simple, add a check in ext4_resize_begin() to make sure that
    the es->s_reserved_gdt_blocks is zero when the resize_inode feature is
    disabled.
    
    Cc: stable@kernel.org
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220601092717.763694-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1d3f02c0ce66656ca7660a69e39431e5e5dafb6
Author: Ding Xiang <dingxiang@cmss.chinamobile.com>
Date:   Mon May 30 18:00:47 2022 +0800

    ext4: make variable "count" signed
    
    commit bc75a6eb856cb1507fa907bf6c1eda91b3fef52f upstream.
    
    Since dx_make_map() may return -EFSCORRUPTED now, so change "count" to
    be a signed integer so we can correctly check for an error code returned
    by dx_make_map().
    
    Fixes: 46c116b920eb ("ext4: verify dir block before splitting it")
    Cc: stable@kernel.org
    Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
    Link: https://lore.kernel.org/r/20220530100047.537598-1-dingxiang@cmss.chinamobile.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a37c1359714da42517dd19d36fc3c4d17edba832
Author: Baokun Li <libaokun1@huawei.com>
Date:   Sat May 28 19:00:15 2022 +0800

    ext4: fix bug_on ext4_mb_use_inode_pa
    
    commit a08f789d2ab5242c07e716baf9a835725046be89 upstream.
    
    Hulk Robot reported a BUG_ON:
    ==================================================================
    kernel BUG at fs/ext4/mballoc.c:3211!
    [...]
    RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f
    [...]
    Call Trace:
     ext4_mb_new_blocks+0x9df/0x5d30
     ext4_ext_map_blocks+0x1803/0x4d80
     ext4_map_blocks+0x3a4/0x1a10
     ext4_writepages+0x126d/0x2c30
     do_writepages+0x7f/0x1b0
     __filemap_fdatawrite_range+0x285/0x3b0
     file_write_and_wait_range+0xb1/0x140
     ext4_sync_file+0x1aa/0xca0
     vfs_fsync_range+0xfb/0x260
     do_fsync+0x48/0xa0
    [...]
    ==================================================================
    
    Above issue may happen as follows:
    -------------------------------------
    do_fsync
     vfs_fsync_range
      ext4_sync_file
       file_write_and_wait_range
        __filemap_fdatawrite_range
         do_writepages
          ext4_writepages
           mpage_map_and_submit_extent
            mpage_map_one_extent
             ext4_map_blocks
              ext4_mb_new_blocks
               ext4_mb_normalize_request
                >>> start + size <= ac->ac_o_ex.fe_logical
               ext4_mb_regular_allocator
                ext4_mb_simple_scan_group
                 ext4_mb_use_best_found
                  ext4_mb_new_preallocation
                   ext4_mb_new_inode_pa
                    ext4_mb_use_inode_pa
                     >>> set ac->ac_b_ex.fe_len <= 0
               ext4_mb_mark_diskspace_used
                >>> BUG_ON(ac->ac_b_ex.fe_len <= 0);
    
    we can easily reproduce this problem with the following commands:
            `fallocate -l100M disk`
            `mkfs.ext4 -b 1024 -g 256 disk`
            `mount disk /mnt`
            `fsstress -d /mnt -l 0 -n 1000 -p 1`
    
    The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP.
    Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur
    when the size is truncated. So start should be the start position of
    the group where ac_o_ex.fe_logical is located after alignment.
    In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP
    is very large, the value calculated by start_off is more accurate.
    
    Cc: stable@kernel.org
    Fixes: cd648b8a8fd5 ("ext4: trim allocation requests to group size")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220528110017.354175-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bdcf89a2d6bd638b3ab0e16603034587c541938
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri May 20 13:35:41 2022 +0300

    serial: 8250: Store to lsr_save_flags after lsr read
    
    commit be03b0651ffd8bab69dfd574c6818b446c0753ce upstream.
    
    Not all LSR register flags are preserved across reads. Therefore, LSR
    readers must store the non-preserved bits into lsr_save_flags.
    
    This fix was initially mixed into feature commit f6f586102add ("serial:
    8250: Handle UART without interrupt on TEMT using em485"). However,
    that feature change had a flaw and it was reverted to make room for
    simpler approach providing the same feature. The embedded fix got
    reverted with the feature change.
    
    Re-add the lsr_save_flags fix and properly mark it's a fix.
    
    Link: https://lore.kernel.org/all/1d6c31d-d194-9e6a-ddf9-5f29af829f3@linux.intel.com/T/#m1737eef986bd20cf19593e344cebd7b0244945fc
    Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
    Cc: stable <stable@kernel.org>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@penugtronix.de>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/f4d774be-1437-a550-8334-19d8722ab98c@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ef6917c0524da5b88496b9706628ffef108b9bb
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 18:02:44 2022 +0400

    usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe
    
    commit 4757c9ade34178b351580133771f510b5ffcf9c8 upstream.
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    of_node_put() will check NULL pointer.
    
    Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220603140246.64529-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 981ee40649e5fd9550f82db1fbb3bfab037da346
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 30 12:54:12 2022 +0400

    usb: dwc2: Fix memory leak in dwc2_hcd_init
    
    commit 3755278f078460b021cd0384562977bf2039a57a upstream.
    
    usb_create_hcd will alloc memory for hcd, and we should
    call usb_put_hcd to free it when platform_get_resource()
    fails to prevent memory leak.
    goto error2 label instead error1 to fix this.
    
    Fixes: 856e6e8e0f93 ("usb: dwc2: check return value after calling platform_get_resource()")
    Cc: stable <stable@kernel.org>
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220530085413.44068-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88dfdbc860c87ddc11186207c4adc7e924f40dee
Author: Robert Eckelmann <longnoserob@gmail.com>
Date:   Sat May 21 23:08:08 2022 +0900

    USB: serial: io_ti: add Agilent E5805A support
    
    commit 908e698f2149c3d6a67d9ae15c75545a3f392559 upstream.
    
    Add support for Agilent E5805A (rebranded ION Edgeport/4) to io_ti.
    
    Signed-off-by: Robert Eckelmann <longnoserob@gmail.com>
    Link: https://lore.kernel.org/r/20220521230808.30931eca@octoberrain
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26cc68790d4e025436aebf5b5fe0eb3482e8e5ee
Author: Slark Xiao <slark_xiao@163.com>
Date:   Wed Jun 1 11:47:40 2022 +0800

    USB: serial: option: add support for Cinterion MV31 with new baseline
    
    commit 158f7585bfcea4aae0ad4128d032a80fec550df1 upstream.
    
    Adding support for Cinterion device MV31 with Qualcomm
    new baseline. Use different PIDs to separate it from
    previous base line products.
    All interfaces settings keep same as previous.
    
    Below is test evidence:
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b8 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B8 USB Mobile Broadband
    S:  SerialNumber=90418e79
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1e2d ProdID=00b9 Rev=04.14
    S:  Manufacturer=Cinterion
    S:  Product=Cinterion PID 0x00B9 USB Mobile Broadband
    S:  SerialNumber=90418e79
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    For PID 00b8, interface 3 is GNSS port which don't use serial driver.
    
    Signed-off-by: Slark Xiao <slark_xiao@163.com>
    Link: https://lore.kernel.org/r/20220601034740.5438-1-slark_xiao@163.com
    [ johan: rename defines using a "2" infix ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 822e23038ee0a81590f0a6b0ee4a70c67951c496
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Tue Jun 7 18:18:19 2022 +0100

    comedi: vmk80xx: fix expression for tx buffer size
    
    commit 242439f7e279d86b3f73b5de724bc67b2f8aeb07 upstream.
    
    The expression for setting the size of the allocated bulk TX buffer
    (`devpriv->usb_tx_buf`) is calling `usb_endpoint_maxp(devpriv->ep_rx)`,
    which is using the wrong endpoint (should be `devpriv->ep_tx`).  Fix it.
    
    Fixes: a23461c47482 ("comedi: vmk80xx: fix transfer-buffer overflow")
    Cc: Johan Hovold <johan@kernel.org>
    Cc: stable@vger.kernel.org # 4.9+
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20220607171819.4121-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 486f68f85085d9b16ae097679b1486dcb1b6eb69
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:25 2022 +0400

    irqchip/gic/realview: Fix refcount leak in realview_gic_of_init
    
    [ Upstream commit f4b98e314888cc51486421bcf6d52852452ea48b ]
    
    of_find_matching_node_and_match() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 82b0a434b436 ("irqchip/gic/realview: Support more RealView DCC variants")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-2-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1baa2f92c74324383ff2e18804f7761b2110e0e2
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Jun 12 02:22:30 2022 +0900

    certs/blacklist_hashes.c: fix const confusion in certs blacklist
    
    [ Upstream commit 6a1c3767d82ed8233de1263aa7da81595e176087 ]
    
    This file fails to compile as follows:
    
      CC      certs/blacklist_hashes.o
    certs/blacklist_hashes.c:4:1: error: ignoring attribute ‘section (".init.data")’ because it conflicts with previous ‘section (".init.rodata")’ [-Werror=attributes]
        4 | const char __initdata *const blacklist_hashes[] = {
          | ^~~~~
    In file included from certs/blacklist_hashes.c:2:
    certs/blacklist.h:5:38: note: previous declaration here
        5 | extern const char __initconst *const blacklist_hashes[];
          |                                      ^~~~~~~~~~~~~~~~
    
    Apply the same fix as commit 2be04df5668d ("certs/blacklist_nohashes.c:
    fix const confusion in certs blacklist").
    
    Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Reviewed-by: Mickaël Salaün <mic@linux.microsoft.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbb14cc9962f69f40a7e4e41b3237d3ecfbb8927
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jun 14 09:09:42 2022 +0100

    arm64: ftrace: fix branch range checks
    
    [ Upstream commit 3eefdf9d1e406f3da47470b2854347009ffcb6fa ]
    
    The branch range checks in ftrace_make_call() and ftrace_make_nop() are
    incorrect, erroneously permitting a forwards branch of 128M and
    erroneously rejecting a backwards branch of 128M.
    
    This is because both functions calculate the offset backwards,
    calculating the offset *from* the target *to* the branch, rather than
    the other way around as the later comparisons expect.
    
    If an out-of-range branch were erroeously permitted, this would later be
    rejected by aarch64_insn_gen_branch_imm() as branch_imm_common() checks
    the bounds correctly, resulting in warnings and the placement of a BRK
    instruction. Note that this can only happen for a forwards branch of
    exactly 128M, and so the caller would need to be exactly 128M bytes
    below the relevant ftrace trampoline.
    
    If an in-range branch were erroeously rejected, then:
    
    * For modules when CONFIG_ARM64_MODULE_PLTS=y, this would result in the
      use of a PLT entry, which is benign.
    
      Note that this is the common case, as this is selected by
      CONFIG_RANDOMIZE_BASE (and therefore RANDOMIZE_MODULE_REGION_FULL),
      which distributions typically seelct. This is also selected by
      CONFIG_ARM64_ERRATUM_843419.
    
    * For modules when CONFIG_ARM64_MODULE_PLTS=n, this would result in
      internal ftrace failures.
    
    * For core kernel text, this would result in internal ftrace failues.
    
      Note that for this to happen, the kernel text would need to be at
      least 128M bytes in size, and typical configurations are smaller tha
      this.
    
    Fix this by calculating the offset *from* the branch *to* the target in
    both functions.
    
    Fixes: f8af0b364e24 ("arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()")
    Fixes: e71a4e1bebaf ("arm64: ftrace: add support for far branches to dynamic ftrace")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
    Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20220614080944.1349146-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd646907b1de935d6e138acc6e0c805824d6e227
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Jun 13 22:53:50 2022 +0200

    net: bgmac: Fix an erroneous kfree() in bgmac_remove()
    
    [ Upstream commit d7dd6eccfbc95ac47a12396f84e7e1b361db654b ]
    
    'bgmac' is part of a managed resource allocated with bgmac_alloc(). It
    should not be freed explicitly.
    
    Remove the erroneous kfree() from the .remove() function.
    
    Fixes: 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/a026153108dd21239036a032b95c25b5cece253b.1655153616.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b689129bf5fa830bb005a72b4450b5e3d012121
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 16:30:26 2022 +0400

    misc: atmel-ssc: Fix IRQ check in ssc_probe
    
    [ Upstream commit 1c245358ce0b13669f6d1625f7a4e05c41f28980 ]
    
    platform_get_irq() returns negative error number instead 0 on failure.
    And the doc of platform_get_irq() provides a usage example:
    
        int irq = platform_get_irq(pdev, 0);
        if (irq < 0)
            return irq;
    
    Fix the check of return value to catch errors correctly.
    
    Fixes: eb1f2930609b ("Driver for the Atmel on-chip SSC on AT32AP and AT91")
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220601123026.7119-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4b0b8edccb0cfb15a8cecf4161e0571d3daac64
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Thu Jun 9 16:17:04 2022 +0200

    tty: goldfish: Fix free_irq() on remove
    
    [ Upstream commit 499e13aac6c762e1e828172b0f0f5275651d6512 ]
    
    Pass the correct dev_id to free_irq() to fix this splat when the driver
    is unbound:
    
     WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq
     Trying to free already-free IRQ 65
     Call Trace:
      warn_slowpath_fmt
      free_irq
      goldfish_tty_remove
      platform_remove
      device_remove
      device_release_driver_internal
      device_driver_detach
      unbind_store
      drv_attr_store
      ...
    
    Fixes: 465893e18878e119 ("tty: goldfish: support platform_device with id -1")
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Link: https://lore.kernel.org/r/20220609141704.1080024-1-vincent.whitchurch@axis.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ba9956ca57e361fb13ea369bb753eb33177acc7
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Thu May 19 16:01:45 2022 +0200

    i40e: Fix call trace in setup_tx_descriptors
    
    [ Upstream commit fd5855e6b1358e816710afee68a1d2bc685176ca ]
    
    After PF reset and ethtool -t there was call trace in dmesg
    sometimes leading to panic. When there was some time, around 5
    seconds, between reset and test there were no errors.
    
    Problem was that pf reset calls i40e_vsi_close in prep_for_reset
    and ethtool -t calls i40e_vsi_close in diag_test. If there was not
    enough time between those commands the second i40e_vsi_close starts
    before previous i40e_vsi_close was done which leads to crash.
    
    Add check to diag_test if pf is in reset and don't start offline
    tests if it is true.
    Add netif_info("testing failed") into unhappy path of i40e_diag_test()
    
    Fixes: e17bc411aea8 ("i40e: Disable offline diagnostics if VFs are enabled")
    Fixes: 510efb2682b3 ("i40e: Fix ethtool offline diagnostic with netqueues")
    Signed-off-by: Michal Jaron <michalx.jaron@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 290e3215f7ee0bb83c03c64efa3e3912df6021f8
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue May 31 11:03:06 2022 -0400

    pNFS: Don't keep retrying if the server replied NFS4ERR_LAYOUTUNAVAILABLE
    
    [ Upstream commit fe44fb23d6ccde4c914c44ef74ab8d9d9ba02bea ]
    
    If the server tells us that a pNFS layout is not available for a
    specific file, then we should not keep pounding it with further
    layoutget requests.
    
    Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7112098b69d5922b7d34c1f6088dad4b0507214e
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 22:07:01 2022 -0400

    random: credit cpu and bootloader seeds by default
    
    [ Upstream commit 846bb97e131d7938847963cca00657c995b1fce1 ]
    
    This commit changes the default Kconfig values of RANDOM_TRUST_CPU and
    RANDOM_TRUST_BOOTLOADER to be Y by default. It does not change any
    existing configs or change any kernel behavior. The reason for this is
    several fold.
    
    As background, I recently had an email thread with the kernel
    maintainers of Fedora/RHEL, Debian, Ubuntu, Gentoo, Arch, NixOS, Alpine,
    SUSE, and Void as recipients. I noted that some distros trust RDRAND,
    some trust EFI, and some trust both, and I asked why or why not. There
    wasn't really much of a "debate" but rather an interesting discussion of
    what the historical reasons have been for this, and it came up that some
    distros just missed the introduction of the bootloader Kconfig knob,
    while another didn't want to enable it until there was a boot time
    switch to turn it off for more concerned users (which has since been
    added). The result of the rather uneventful discussion is that every
    major Linux distro enables these two options by default.
    
    While I didn't have really too strong of an opinion going into this
    thread -- and I mostly wanted to learn what the distros' thinking was
    one way or another -- ultimately I think their choice was a decent
    enough one for a default option (which can be disabled at boot time).
    I'll try to summarize the pros and cons:
    
    Pros:
    
    - The RNG machinery gets initialized super quickly, and there's no
      messing around with subsequent blocking behavior.
    
    - The bootloader mechanism is used by kexec in order for the prior
      kernel to initialize the RNG of the next kernel, which increases
      the entropy available to early boot daemons of the next kernel.
    
    - Previous objections related to backdoors centered around
      Dual_EC_DRBG-like kleptographic systems, in which observing some
      amount of the output stream enables an adversary holding the right key
      to determine the entire output stream.
    
      This used to be a partially justified concern, because RDRAND output
      was mixed into the output stream in varying ways, some of which may
      have lacked pre-image resistance (e.g. XOR or an LFSR).
    
      But this is no longer the case. Now, all usage of RDRAND and
      bootloader seeds go through a cryptographic hash function. This means
      that the CPU would have to compute a hash pre-image, which is not
      considered to be feasible (otherwise the hash function would be
      terribly broken).
    
    - More generally, if the CPU is backdoored, the RNG is probably not the
      realistic vector of choice for an attacker.
    
    - These CPU or bootloader seeds are far from being the only source of
      entropy. Rather, there is generally a pretty huge amount of entropy,
      not all of which is credited, especially on CPUs that support
      instructions like RDRAND. In other words, assuming RDRAND outputs all
      zeros, an attacker would *still* have to accurately model every single
      other entropy source also in use.
    
    - The RNG now reseeds itself quite rapidly during boot, starting at 2
      seconds, then 4, then 8, then 16, and so forth, so that other sources
      of entropy get used without much delay.
    
    - Paranoid users can set random.trust_{cpu,bootloader}=no in the kernel
      command line, and paranoid system builders can set the Kconfig options
      to N, so there's no reduction or restriction of optionality.
    
    - It's a practical default.
    
    - All the distros have it set this way. Microsoft and Apple trust it
      too. Bandwagon.
    
    Cons:
    
    - RDRAND *could* still be backdoored with something like a fixed key or
      limited space serial number seed or another indexable scheme like
      that. (However, it's hard to imagine threat models where the CPU is
      backdoored like this, yet people are still okay making *any*
      computations with it or connecting it to networks, etc.)
    
    - RDRAND *could* be defective, rather than backdoored, and produce
      garbage that is in one way or another insufficient for crypto.
    
    - Suggesting a *reduction* in paranoia, as this commit effectively does,
      may cause some to question my personal integrity as a "security
      person".
    
    - Bootloader seeds and RDRAND are generally very difficult if not all
      together impossible to audit.
    
    Keep in mind that this doesn't actually change any behavior. This
    is just a change in the default Kconfig value. The distros already are
    shipping kernels that set things this way.
    
    Ard made an additional argument in [1]:
    
        We're at the mercy of firmware and micro-architecture anyway, given
        that we are also relying on it to ensure that every instruction in
        the kernel's executable image has been faithfully copied to memory,
        and that the CPU implements those instructions as documented. So I
        don't think firmware or ISA bugs related to RNGs deserve special
        treatment - if they are broken, we should quirk around them like we
        usually do. So enabling these by default is a step in the right
        direction IMHO.
    
    In [2], Phil pointed out that having this disabled masked a bug that CI
    otherwise would have caught:
    
        A clean 5.15.45 boots cleanly, whereas a downstream kernel shows the
        static key warning (but it does go on to boot). The significant
        difference is that our defconfigs set CONFIG_RANDOM_TRUST_BOOTLOADER=y
        defining that on top of multi_v7_defconfig demonstrates the issue on
        a clean 5.15.45. Conversely, not setting that option in a
        downstream kernel build avoids the warning
    
    [1] https://lore.kernel.org/lkml/CAMj1kXGi+ieviFjXv9zQBSaGyyzeGW_VpMpTLJK8PJb2QHEQ-w@mail.gmail.com/
    [2] https://lore.kernel.org/lkml/c47c42e3-1d56-5859-a6ad-976a1a3381c6@raspberrypi.com/
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c1f4408c9818ff2a6a39927ce6f176bf237d1b8
Author: Chen Lin <chen45464546@163.com>
Date:   Wed Jun 8 20:46:53 2022 +0800

    net: ethernet: mtk_eth_soc: fix misuse of mem alloc interface netdev[napi]_alloc_frag
    
    [ Upstream commit 2f2c0d2919a14002760f89f4e02960c735a316d2 ]
    
    When rx_flag == MTK_RX_FLAGS_HWLRO,
    rx_data_len = MTK_MAX_LRO_RX_LENGTH(4096 * 3) > PAGE_SIZE.
    netdev_alloc_frag is for alloction of page fragment only.
    Reference to other drivers and Documentation/vm/page_frags.rst
    
    Branch to use __get_free_pages when ring->frag_size > PAGE_SIZE.
    
    Signed-off-by: Chen Lin <chen45464546@163.com>
    Link: https://lore.kernel.org/r/1654692413-2598-1-git-send-email-chen45464546@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e818d433fc2718fe4da044ffca7431812a7e04e
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Tue Jun 7 20:00:28 2022 +0800

    ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg
    
    [ Upstream commit f638a84afef3dfe10554c51820c16e39a278c915 ]
    
    When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be
    overflow. To fix, we can follow what udpv6 does and subtract the
    transhdrlen from the max.
    
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Link: https://lore.kernel.org/r/20220607120028.845916-2-wangyufen@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f21f908347712b8288ffe83b531b5e977042b29c
Author: Xiaohui Zhang <xiaohuizhang@ruc.edu.cn>
Date:   Tue Jun 7 16:32:30 2022 +0800

    nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
    
    [ Upstream commit 8a4d480702b71184fabcf379b80bf7539716752e ]
    
    Similar to the handling of play_deferred in commit 19cfe912c37b
    ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought
    a patch might be needed here as well.
    
    Currently usb_submit_urb is called directly to submit deferred tx
    urbs after unanchor them.
    
    So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
    and cause memory leak.
    
    Put those urbs in tx_anchor to avoid the leak, and also fix the error
    handling.
    
    Signed-off-by: Xiaohui Zhang <xiaohuizhang@ruc.edu.cn>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220607083230.6182-1-xiaohuizhang@ruc.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eef6d16cce8299491e42b820839534b1cd3bedfc
Author: chengkaitao <pilgrimtao@gmail.com>
Date:   Thu Jun 2 08:55:42 2022 +0800

    virtio-mmio: fix missing put_device() when vm_cmdline_parent registration failed
    
    [ Upstream commit a58a7f97ba11391d2d0d408e0b24f38d86ae748e ]
    
    The reference must be released when device_register(&vm_cmdline_parent)
    failed. Add the corresponding 'put_device()' in the error handling path.
    
    Signed-off-by: chengkaitao <pilgrimtao@gmail.com>
    Message-Id: <20220602005542.16489-1-chengkaitao@didiglobal.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2f6262132cd6e5eb04e64f1dfbaab611ee5df73
Author: Chengguang Xu <cgxu519@mykernel.net>
Date:   Sun May 29 23:34:55 2022 +0800

    scsi: pmcraid: Fix missing resource cleanup in error case
    
    [ Upstream commit ec1e8adcbdf661c57c395bca342945f4f815add7 ]
    
    Fix missing resource cleanup (when '(--i) == 0') for error case in
    pmcraid_register_interrupt_handler().
    
    Link: https://lore.kernel.org/r/20220529153456.4183738-6-cgxu519@mykernel.net
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ae7bde77f345e8f9a3d21dcdc6f6bde5fb38582
Author: Chengguang Xu <cgxu519@mykernel.net>
Date:   Sun May 29 23:34:53 2022 +0800

    scsi: ipr: Fix missing/incorrect resource cleanup in error case
    
    [ Upstream commit d64c491911322af1dcada98e5b9ee0d87e8c8fee ]
    
    Fix missing resource cleanup (when '(--i) == 0') for error case in
    ipr_alloc_mem() and skip incorrect resource cleanup (when '(--i) == 0') for
    error case in ipr_request_other_msi_irqs() because variable i started from
    1.
    
    Link: https://lore.kernel.org/r/20220529153456.4183738-4-cgxu519@mykernel.net
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee2eec0988fe24dbdc9cf7f8c3378529dcbf0ddf
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:26 2022 -0700

    scsi: lpfc: Fix port stuck in bypassed state after LIP in PT2PT topology
    
    [ Upstream commit 336d63615466b4c06b9401c987813fd19bdde39b ]
    
    After issuing a LIP, a specific target vendor does not ACC the FLOGI that
    lpfc sends.  However, it does send its own FLOGI that lpfc ACCs.  The
    target then establishes the port IDs by sending a PLOGI.  lpfc PLOGI_ACCs
    and starts the RPI registration for DID 0x000001.  The target then sends a
    LOGO to the fabric DID.  lpfc is currently treating the LOGO from the
    fabric DID as a link down and cleans up all the ndlps.  The ndlp for DID
    0x000001 is put back into NPR and discovery stops, leaving the port in
    stuck in bypassed mode.
    
    Change lpfc behavior such that if a LOGO is received for the fabric DID in
    PT2PT topology skip the lpfc_linkdown_port() routine and just move the
    fabric DID back to NPR.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-7-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b6564795e83cec2728f1dae3dc6b5c5d77b65a4
Author: Wentao Wang <wwentao@vmware.com>
Date:   Thu Jun 2 08:57:00 2022 +0000

    scsi: vmw_pvscsi: Expand vcpuHint to 16 bits
    
    [ Upstream commit cf71d59c2eceadfcde0fb52e237990a0909880d7 ]
    
    vcpuHint has been expanded to 16 bit on host to enable routing to more
    CPUs. Guest side should align with the change. This change has been tested
    with hosts with 8-bit and 16-bit vcpuHint, on both platforms host side can
    get correct value.
    
    Link: https://lore.kernel.org/r/EF35F4D5-5DCC-42C5-BCC4-29DF1729B24C@vmware.com
    Signed-off-by: Wentao Wang <wwentao@vmware.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fa58a760405209e05610a341ed18c1147453097
Author: Adam Ford <aford173@gmail.com>
Date:   Thu May 26 13:21:28 2022 -0500

    ASoC: wm8962: Fix suspend while playing music
    
    [ Upstream commit d1f5272c0f7d2e53c6f2480f46725442776f5f78 ]
    
    If the audio CODEC is playing sound when the system is suspended,
    it can be left in a state which throws the following error:
    
    wm8962 3-001a: ASoC: error at soc_component_read_no_lock on wm8962.3-001a: -16
    
    Once this error has occurred, the audio will not work again until rebooted.
    
    Fix this by configuring SET_SYSTEM_SLEEP_PM_OPS.
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220526182129.538472-1-aford173@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ac5efee33f29e704226506d429b84575a5d66f8
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sat May 21 23:34:10 2022 +0300

    ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()
    
    [ Upstream commit bf476fe22aa1851bab4728e0c49025a6a0bea307 ]
    
    In an unlikely (and probably wrong?) case that the 'ppi' parameter of
    ata_host_alloc_pinfo() points to an array starting with a NULL pointer,
    there's going to be a kernel oops as the 'pi' local variable won't get
    reassigned from the initial value of NULL. Initialize 'pi' instead to
    '&ata_dummy_port_info' to fix the possible kernel oops for good...
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE static
    analysis tool.
    
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74301547327ea715eed0e9010efb2ccab826b953
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:18 2022 +0100

    ASoC: cs42l56: Correct typo in minimum level for SX volume controls
    
    [ Upstream commit a8928ada9b96944cadd8b65d191e33199fd38782 ]
    
    A couple of the SX volume controls specify 0x84 as the lowest volume
    value, however the correct value from the datasheet is 0x44. The
    datasheet don't include spaces in the value it displays as binary so
    this was almost certainly just a typo reading 1000100.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-6-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f469f0145efd8f307c9b6c8a2024e1747495ab42
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:17 2022 +0100

    ASoC: cs42l52: Correct TLV for Bypass Volume
    
    [ Upstream commit 91e90c712fade0b69cdff7cc6512f6099bd18ae5 ]
    
    The Bypass Volume is accidentally using a -6dB minimum TLV rather than
    the correct -60dB minimum. Add a new TLV to correct this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-5-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9892f40eead30aa668c43e744bd021d0cc7313b
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:16 2022 +0100

    ASoC: cs53l30: Correct number of volume levels on SX controls
    
    [ Upstream commit 7fbd6dd68127927e844912a16741016d432a0737 ]
    
    This driver specified the maximum value rather than the number of volume
    levels on the SX controls, this is incorrect, so correct them.
    
    Reported-by: David Rhodes <david.rhodes@cirrus.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-4-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c44eafbd13c982c8dd9fed196b9eedeb9685db9a
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:14 2022 +0100

    ASoC: cs42l52: Fix TLV scales for mixer controls
    
    [ Upstream commit 8bf5aabf524eec61013e506f764a0b2652dc5665 ]
    
    The datasheet specifies the range of the mixer volumes as between
    -51.5dB and 12dB with a 0.5dB step. Update the TLVs for this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-2-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4bfd4858d28f0a6f7f1279b17560d30faaac5f5
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jun 7 17:04:38 2022 +0200

    random: account for arch randomness in bits
    
    commit 77fc95f8c0dc9e1f8e620ec14d2fb65028fb7adc upstream.
    
    Rather than accounting in bytes and multiplying (shifting), we can just
    account in bits and avoid the shift. The main motivation for this is
    there are other patches in flux that expand this code a bit, and
    avoiding the duplication of "* 8" everywhere makes things a bit clearer.
    
    Cc: stable@vger.kernel.org
    Fixes: 12e45a2a6308 ("random: credit architectural init the exact amount")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e70c1a8eea10963080c61c3a973f525274eeb31
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jun 7 17:00:16 2022 +0200

    random: mark bootloader randomness code as __init
    
    commit 39e0f991a62ed5efabd20711a7b6e7da92603170 upstream.
    
    add_bootloader_randomness() and the variables it touches are only used
    during __init and not after, so mark these as __init. At the same time,
    unexport this, since it's only called by other __init code that's
    built-in.
    
    Cc: stable@vger.kernel.org
    Fixes: 428826f5358c ("fdt: add support for rng-seed")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aafc845f74e40f7c8f4ade6424c413b71f320f89
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jun 7 09:44:07 2022 +0200

    random: avoid checking crng_ready() twice in random_init()
    
    commit 9b29b6b20376ab64e1b043df6301d8a92378e631 upstream.
    
    The current flow expands to:
    
        if (crng_ready())
           ...
        else if (...)
            if (!crng_ready())
                ...
    
    The second crng_ready() call is redundant, but can't so easily be
    optimized out by the compiler.
    
    This commit simplifies that to:
    
        if (crng_ready()
            ...
        else if (...)
            ...
    
    Fixes: 560181c27b58 ("random: move initialization functions out of hot pages")
    Cc: stable@vger.kernel.org
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ed7b5bf2c4cea81e87e8f72e9a0670163a7bb59
Author: Nicolai Stange <nstange@suse.de>
Date:   Thu Jun 2 22:22:32 2022 +0200

    crypto: drbg - make reseeding from get_random_bytes() synchronous
    
    commit 074bcd4000e0d812bc253f86fedc40f81ed59ccc upstream.
    
    get_random_bytes() usually hasn't full entropy available by the time DRBG
    instances are first getting seeded from it during boot. Thus, the DRBG
    implementation registers random_ready_callbacks which would in turn
    schedule some work for reseeding the DRBGs once get_random_bytes() has
    sufficient entropy available.
    
    For reference, the relevant history around handling DRBG (re)seeding in
    the context of a not yet fully seeded get_random_bytes() is:
    
      commit 16b369a91d0d ("random: Blocking API for accessing
                            nonblocking_pool")
      commit 4c7879907edd ("crypto: drbg - add async seeding operation")
    
      commit 205a525c3342 ("random: Add callback API for random pool
                            readiness")
      commit 57225e679788 ("crypto: drbg - Use callback API for random
                            readiness")
      commit c2719503f5e1 ("random: Remove kernel blocking API")
    
    However, some time later, the initialization state of get_random_bytes()
    has been made queryable via rng_is_initialized() introduced with commit
    9a47249d444d ("random: Make crng state queryable"). This primitive now
    allows for streamlining the DRBG reseeding from get_random_bytes() by
    replacing that aforementioned asynchronous work scheduling from
    random_ready_callbacks with some simpler, synchronous code in
    drbg_generate() next to the related logic already present therein. Apart
    from improving overall code readability, this change will also enable DRBG
    users to rely on wait_for_random_bytes() for ensuring that the initial
    seeding has completed, if desired.
    
    The previous patches already laid the grounds by making drbg_seed() to
    record at each DRBG instance whether it was being seeded at a time when
    rng_is_initialized() still had been false as indicated by
    ->seeded == DRBG_SEED_STATE_PARTIAL.
    
    All that remains to be done now is to make drbg_generate() check for this
    condition, determine whether rng_is_initialized() has flipped to true in
    the meanwhile and invoke a reseed from get_random_bytes() if so.
    
    Make this move:
    - rename the former drbg_async_seed() work handler, i.e. the one in charge
      of reseeding a DRBG instance from get_random_bytes(), to
      "drbg_seed_from_random()",
    - change its signature as appropriate, i.e. make it take a struct
      drbg_state rather than a work_struct and change its return type from
      "void" to "int" in order to allow for passing error information from
      e.g. its __drbg_seed() invocation onwards to callers,
    - make drbg_generate() invoke this drbg_seed_from_random() once it
      encounters a DRBG instance with ->seeded == DRBG_SEED_STATE_PARTIAL by
      the time rng_is_initialized() has flipped to true and
    - prune everything related to the former, random_ready_callback based
      mechanism.
    
    As drbg_seed_from_random() is now getting invoked from drbg_generate() with
    the ->drbg_mutex being held, it must not attempt to recursively grab it
    once again. Remove the corresponding mutex operations from what is now
    drbg_seed_from_random(). Furthermore, as drbg_seed_from_random() can now
    report errors directly to its caller, there's no need for it to temporarily
    switch the DRBG's ->seeded state to DRBG_SEED_STATE_UNSEEDED so that a
    failure of the subsequently invoked __drbg_seed() will get signaled to
    drbg_generate(). Don't do it then.
    
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [Jason: for stable, undid the modifications for the backport of 5acd3548.]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb86176aea774689fcfa9afb59b9ae7c6151d0e2
Author: Stephan Müller <smueller@chronox.de>
Date:   Sun Jun 7 15:20:26 2020 +0200

    crypto: drbg - always try to free Jitter RNG instance
    
    commit 819966c06b759022e9932f328284314d9272b9f3 upstream.
    
    The Jitter RNG is unconditionally allocated as a seed source follwoing
    the patch 97f2650e5040. Thus, the instance must always be deallocated.
    
    Reported-by: syzbot+2e635807decef724a1fa@syzkaller.appspotmail.com
    Fixes: 97f2650e5040 ("crypto: drbg - always seeded with SP800-90B ...")
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31a5afe0696ca7c55ddc8a4b87c02863013f14d0
Author: Nicolai Stange <nstange@suse.de>
Date:   Thu Jun 2 22:22:31 2022 +0200

    crypto: drbg - move dynamic ->reseed_threshold adjustments to __drbg_seed()
    
    commit 262d83a4290c331cd4f617a457408bdb82fbb738 upstream.
    
    Since commit 42ea507fae1a ("crypto: drbg - reseed often if seedsource is
    degraded"), the maximum seed lifetime represented by ->reseed_threshold
    gets temporarily lowered if the get_random_bytes() source cannot provide
    sufficient entropy yet, as is common during boot, and restored back to
    the original value again once that has changed.
    
    More specifically, if the add_random_ready_callback() invoked from
    drbg_prepare_hrng() in the course of DRBG instantiation does not return
    -EALREADY, that is, if get_random_bytes() has not been fully initialized
    at this point yet, drbg_prepare_hrng() will lower ->reseed_threshold
    to a value of 50. The drbg_async_seed() scheduled from said
    random_ready_callback will eventually restore the original value.
    
    A future patch will replace the random_ready_callback based notification
    mechanism and thus, there will be no add_random_ready_callback() return
    value anymore which could get compared to -EALREADY.
    
    However, there's __drbg_seed() which gets invoked in the course of both,
    the DRBG instantiation as well as the eventual reseeding from
    get_random_bytes() in aforementioned drbg_async_seed(), if any. Moreover,
    it knows about the get_random_bytes() initialization state by the time the
    seed data had been obtained from it: the new_seed_state argument introduced
    with the previous patch would get set to DRBG_SEED_STATE_PARTIAL in case
    get_random_bytes() had not been fully initialized yet and to
    DRBG_SEED_STATE_FULL otherwise. Thus, __drbg_seed() provides a convenient
    alternative for managing that ->reseed_threshold lowering and restoring at
    a central place.
    
    Move all ->reseed_threshold adjustment code from drbg_prepare_hrng() and
    drbg_async_seed() respectively to __drbg_seed(). Make __drbg_seed()
    lower the ->reseed_threshold to 50 in case its new_seed_state argument
    equals DRBG_SEED_STATE_PARTIAL and let it restore the original value
    otherwise.
    
    There is no change in behaviour.
    
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Reviewed-by: Stephan Müller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b05392dc67af9eab0b7e7c1809cd2fc84756e0de
Author: Nicolai Stange <nstange@suse.de>
Date:   Thu Jun 2 22:22:30 2022 +0200

    crypto: drbg - track whether DRBG was seeded with !rng_is_initialized()
    
    commit 2bcd25443868aa8863779a6ebc6c9319633025d2 upstream.
    
    Currently, the DRBG implementation schedules asynchronous works from
    random_ready_callbacks for reseeding the DRBG instances with output from
    get_random_bytes() once the latter has sufficient entropy available.
    
    However, as the get_random_bytes() initialization state can get queried by
    means of rng_is_initialized() now, there is no real need for this
    asynchronous reseeding logic anymore and it's better to keep things simple
    by doing it synchronously when needed instead, i.e. from drbg_generate()
    once rng_is_initialized() has flipped to true.
    
    Of course, for this to work, drbg_generate() would need some means by which
    it can tell whether or not rng_is_initialized() has flipped to true since
    the last seeding from get_random_bytes(). Or equivalently, whether or not
    the last seed from get_random_bytes() has happened when
    rng_is_initialized() was still evaluating to false.
    
    As it currently stands, enum drbg_seed_state allows for the representation
    of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and
    DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full
    reseeding operation involving both, the rather expensive jitterentropy as
    well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL
    state on the other hand implies that no reseeding at all is required for a
    !->pr DRBG variant.
    
    Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for
    representing the condition that a DRBG was being seeded when
    rng_is_initialized() had still been false. In particular, this new state
    implies that
    - the given DRBG instance has been fully seeded from the jitterentropy
      source (if enabled)
    - and drbg_generate() is supposed to reseed from get_random_bytes()
      *only* once rng_is_initialized() turns to true.
    
    Up to now, the __drbg_seed() helper used to set the given DRBG instance's
    ->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument
    allowing for the specification of the to be written ->seeded value instead.
    Make the first of its two callers, drbg_seed(), determine the appropriate
    value based on rng_is_initialized(). The remaining caller,
    drbg_async_seed(), is known to get invoked only once rng_is_initialized()
    is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new
    argument to __drbg_seed().
    
    There is no change in behaviour, except for that the pr_devel() in
    drbg_generate() would now report "unseeded" for ->pr DRBG instances which
    had last been seeded when rng_is_initialized() was still evaluating to
    false.
    
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Reviewed-by: Stephan Müller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1fb007ad8dbdebc6558a985917b627838c1a244
Author: Nicolai Stange <nstange@suse.de>
Date:   Thu Jun 2 22:22:29 2022 +0200

    crypto: drbg - prepare for more fine-grained tracking of seeding state
    
    commit ce8ce31b2c5c8b18667784b8c515650c65d57b4e upstream.
    
    There are two different randomness sources the DRBGs are getting seeded
    from, namely the jitterentropy source (if enabled) and get_random_bytes().
    At initial DRBG seeding time during boot, the latter might not have
    collected sufficient entropy for seeding itself yet and thus, the DRBG
    implementation schedules a reseed work from a random_ready_callback once
    that has happened. This is particularly important for the !->pr DRBG
    instances, for which (almost) no further reseeds are getting triggered
    during their lifetime.
    
    Because collecting data from the jitterentropy source is a rather expensive
    operation, the aforementioned asynchronously scheduled reseed work
    restricts itself to get_random_bytes() only. That is, it in some sense
    amends the initial DRBG seed derived from jitterentropy output at full
    (estimated) entropy with fresh randomness obtained from get_random_bytes()
    once that has been seeded with sufficient entropy itself.
    
    With the advent of rng_is_initialized(), there is no real need for doing
    the reseed operation from an asynchronously scheduled work anymore and a
    subsequent patch will make it synchronous by moving it next to related
    logic already present in drbg_generate().
    
    However, for tracking whether a full reseed including the jitterentropy
    source is required or a "partial" reseed involving only get_random_bytes()
    would be sufficient already, the boolean struct drbg_state's ->seeded
    member must become a tristate value.
    
    Prepare for this by introducing the new enum drbg_seed_state and change
    struct drbg_state's ->seeded member's type from bool to that type.
    
    For facilitating review, enum drbg_seed_state is made to only contain
    two members corresponding to the former ->seeded values of false and true
    resp. at this point: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. A
    third one for tracking the intermediate state of "seeded from jitterentropy
    only" will be introduced with a subsequent patch.
    
    There is no change in behaviour at this point.
    
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Reviewed-by: Stephan Müller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80bc8308b5fffbafed7b59267e34ea4040d2babb
Author: Stephan Müller <smueller@chronox.de>
Date:   Fri Apr 17 21:34:03 2020 +0200

    crypto: drbg - always seeded with SP800-90B compliant noise source
    
    commit 97f2650e504033376e8813691cb6eccf73151676 upstream.
    
    As the Jitter RNG provides an SP800-90B compliant noise source, use this
    noise source always for the (re)seeding of the DRBG.
    
    To make sure the DRBG is always properly seeded, the reseed threshold
    is reduced to 1<<20 generate operations.
    
    The Jitter RNG may report health test failures. Such health test
    failures are treated as transient as follows. The DRBG will not reseed
    from the Jitter RNG (but from get_random_bytes) in case of a health
    test failure. Though, it produces the requested random number.
    
    The Jitter RNG has a failure counter where at most 1024 consecutive
    resets due to a health test failure are considered as a transient error.
    If more consecutive resets are required, the Jitter RNG will return
    a permanent error which is returned to the caller by the DRBG. With this
    approach, the worst case reseed threshold is significantly lower than
    mandated by SP800-90A in order to seed with an SP800-90B noise source:
    the DRBG has a reseed threshold of 2^20 * 1024 = 2^30 generate requests.
    
    Yet, in case of a transient Jitter RNG health test failure, the DRBG is
    seeded with the data obtained from get_random_bytes.
    
    However, if the Jitter RNG fails during the initial seeding operation
    even due to a health test error, the DRBG will send an error to the
    caller because at that time, the DRBG has received no seed that is
    SP800-90B compliant.
    
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c03d07329480962ede9663df68ba11ed2939338
Author: Stephan Mueller <smueller@chronox.de>
Date:   Wed May 8 16:19:24 2019 +0200

    crypto: drbg - add FIPS 140-2 CTRNG for noise source
    
    commit db07cd26ac6a418dc2823187958edcfdb415fa83 upstream.
    
    FIPS 140-2 section 4.9.2 requires a continuous self test of the noise
    source. Up to kernel 4.8 drivers/char/random.c provided this continuous
    self test. Afterwards it was moved to a location that is inconsistent
    with the FIPS 140-2 requirements. The relevant patch was
    e192be9d9a30555aae2ca1dc3aad37cba484cd4a .
    
    Thus, the FIPS 140-2 CTRNG is added to the DRBG when it obtains the
    seed. This patch resurrects the function drbg_fips_continous_test that
    existed some time ago and applies it to the noise sources. The patch
    that removed the drbg_fips_continous_test was
    b3614763059b82c26bdd02ffcb1c016c1132aad0 .
    
    The Jitter RNG implements its own FIPS 140-2 self test and thus does not
    need to be subjected to the test in the DRBG.
    
    The patch contains a tiny fix to ensure proper zeroization in case of an
    error during the Jitter RNG data gathering.
    
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Reviewed-by: Yann Droneaud <ydroneaud@opteya.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcff2416844d91acee3cf1079fe89dcdd6feb075
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jun 7 10:40:05 2022 +0200

    Revert "random: use static branch for crng_ready()"
    
    This reverts upstream commit f5bda35fba615ace70a656d4700423fa6c9bebee
    from stable. It's not essential and will take some time during 5.19 to
    work out properly.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09b3d3579fd3f6ed89e1ecb2542979ed41856746
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun May 22 22:25:41 2022 +0200

    random: check for signals after page of pool writes
    
    commit 1ce6c8d68f8ac587f54d0a271ac594d3d51f3efb upstream.
    
    get_random_bytes_user() checks for signals after producing a PAGE_SIZE
    worth of output, just like /dev/zero does. write_pool() is doing
    basically the same work (actually, slightly more expensive), and so
    should stop to check for signals in the same way. Let's also name it
    write_pool_user() to match get_random_bytes_user(), so this won't be
    misused in the future.
    
    Before this patch, massive writes to /dev/urandom would tie up the
    process for an extremely long time and make it unterminatable. After, it
    can be successfully interrupted. The following test program can be used
    to see this works as intended:
    
      #include <unistd.h>
      #include <fcntl.h>
      #include <signal.h>
      #include <stdio.h>
    
      static unsigned char x[~0U];
    
      static void handle(int) { }
    
      int main(int argc, char *argv[])
      {
        pid_t pid = getpid(), child;
        int fd;
        signal(SIGUSR1, handle);
        if (!(child = fork())) {
          for (;;)
            kill(pid, SIGUSR1);
        }
        fd = open("/dev/urandom", O_WRONLY);
        pause();
        printf("interrupted after writing %zd bytes\n", write(fd, x, sizeof(x)));
        close(fd);
        kill(child, SIGTERM);
        return 0;
      }
    
    Result before: "interrupted after writing 2147479552 bytes"
    Result after: "interrupted after writing 4096 bytes"
    
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72389322c99c2e9c782565a4ff109b511468a864
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu May 19 17:31:37 2022 -0600

    random: wire up fops->splice_{read,write}_iter()
    
    commit 79025e727a846be6fd215ae9cdb654368ac3f9a6 upstream.
    
    Now that random/urandom is using {read,write}_iter, we can wire it up to
    using the generic splice handlers.
    
    Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [Jason: added the splice_write path. Note that sendfile() and such still
     does not work for read, though it does for write, because of a file
     type restriction in splice_direct_to_actor(), which I'll address
     separately.]
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17685dd543f9c8af51aa888aa7e7eab498e8f07d
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu May 19 17:43:15 2022 -0600

    random: convert to using fops->write_iter()
    
    commit 22b0a222af4df8ee9bb8e07013ab44da9511b047 upstream.
    
    Now that the read side has been converted to fix a regression with
    splice, convert the write side as well to have some symmetry in the
    interface used (and help deprecate ->write()).
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [Jason: cleaned up random_ioctl a bit, require full writes in
     RNDADDENTROPY since it's crediting entropy, simplify control flow of
     write_pool(), and incorporate suggestions from Al.]
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 225c0df138c2d54fd0b4a5787fd6cc537962c1a0
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat May 14 13:59:30 2022 +0200

    random: move randomize_page() into mm where it belongs
    
    commit 5ad7dd882e45d7fe432c32e896e2aaa0b21746ea upstream.
    
    randomize_page is an mm function. It is documented like one. It contains
    the history of one. It has the naming convention of one. It looks
    just like another very similar function in mm, randomize_stack_top().
    And it has always been maintained and updated by mm people. There is no
    need for it to be in random.c. In the "which shape does not look like
    the other ones" test, pointing to randomize_page() is correct.
    
    So move randomize_page() into mm/util.c, right next to the similar
    randomize_stack_top() function.
    
    This commit contains no actual code changes.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d77e58eef686f1e3d5ed633f546a3ef927e05ffd
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 13 16:17:12 2022 +0200

    random: move initialization functions out of hot pages
    
    commit 560181c27b582557d633ecb608110075433383af upstream.
    
    Much of random.c is devoted to initializing the rng and accounting for
    when a sufficient amount of entropy has been added. In a perfect world,
    this would all happen during init, and so we could mark these functions
    as __init. But in reality, this isn't the case: sometimes the rng only
    finishes initializing some seconds after system init is finished.
    
    For this reason, at the moment, a whole host of functions that are only
    used relatively close to system init and then never again are intermixed
    with functions that are used in hot code all the time. This creates more
    cache misses than necessary.
    
    In order to pack the hot code closer together, this commit moves the
    initialization functions that can't be marked as __init into
    .text.unlikely by way of the __cold attribute.
    
    Of particular note is moving credit_init_bits() into a macro wrapper
    that inlines the crng_ready() static branch check. This avoids a
    function call to a nop+ret, and most notably prevents extra entropy
    arithmetic from being computed in mix_interrupt_randomness().
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    [ Jason: for stable, made sure the printk_deferred was a pr_notice,
      because those caused problems on ≤ 4.19 according to commit logs. ]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25f97736b67d63dc5244cd7fdeadf3fab382fb0b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 13 12:32:23 2022 +0200

    random: use proper return types on get_random_{int,long}_wait()
    
    commit 7c3a8a1db5e03d02cc0abb3357a84b8b326dfac3 upstream.
    
    Before these were returning signed values, but the API is intended to be
    used with unsigned values.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c24fb5a30cd0330e47c95ad5e7f66e066879ce0f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 13 12:29:38 2022 +0200

    random: remove extern from functions in header
    
    commit 7782cfeca7d420e8bb707613d4cfb0f7ff29bb3a upstream.
    
    Accoriding to the kernel style guide, having `extern` on functions in
    headers is old school and deprecated, and doesn't add anything. So remove
    them from random.h, and tidy up the file a little bit too.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0eabe217548a1526ef5a43364bea4073a12db1a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue May 3 15:30:45 2022 +0200

    random: use static branch for crng_ready()
    
    commit f5bda35fba615ace70a656d4700423fa6c9bebee upstream.
    
    Since crng_ready() is only false briefly during initialization and then
    forever after becomes true, we don't need to evaluate it after, making
    it a prime candidate for a static branch.
    
    One complication, however, is that it changes state in a particular call
    to credit_init_bits(), which might be made from atomic context, which
    means we must kick off a workqueue to change the static key. Further
    complicating things, credit_init_bits() may be called sufficiently early
    on in system initialization such that system_wq is NULL.
    
    Fortunately, there exists the nice function execute_in_process_context(),
    which will immediately execute the function if !in_interrupt(), and
    otherwise defer it to a workqueue. During early init, before workqueues
    are available, in_interrupt() is always false, because interrupts
    haven't even been enabled yet, which means the function in that case
    executes immediately. Later on, after workqueues are available,
    in_interrupt() might be true, but in that case, the work is queued in
    system_wq and all goes well.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Sultan Alsawaf <sultan@kerneltoast.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37fe03f2708ed67eb642613860b2b4db6d0e08b7
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu May 12 15:32:26 2022 +0200

    random: credit architectural init the exact amount
    
    commit 12e45a2a6308105469968951e6d563e8f4fea187 upstream.
    
    RDRAND and RDSEED can fail sometimes, which is fine. We currently
    initialize the RNG with 512 bits of RDRAND/RDSEED. We only need 256 bits
    of those to succeed in order to initialize the RNG. Instead of the
    current "all or nothing" approach, actually credit these contributions
    the amount that is actually contributed.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b16b1b66b7d47e09813a033ce52e954afeb505dd
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu May 5 02:20:22 2022 +0200

    random: handle latent entropy and command line from random_init()
    
    commit 2f14062bb14b0fcfcc21e6dc7d5b5c0d25966164 upstream.
    
    Currently, start_kernel() adds latent entropy and the command line to
    the entropy bool *after* the RNG has been initialized, deferring when
    it's actually used by things like stack canaries until the next time
    the pool is seeded. This surely is not intended.
    
    Rather than splitting up which entropy gets added where and when between
    start_kernel() and random_init(), just do everything in random_init(),
    which should eliminate these kinds of bugs in the future.
    
    While we're at it, rename the awkwardly titled "rand_initialize()" to
    the more standard "random_init()" nomenclature.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bed234f23cdcbcc5dba4e3f3db8c0273eb393c2
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue May 10 15:20:42 2022 +0200

    random: use proper jiffies comparison macro
    
    commit 8a5b8a4a4ceb353b4dd5bafd09e2b15751bcdb51 upstream.
    
    This expands to exactly the same code that it replaces, but makes things
    consistent by using the same macro for jiffy comparisons throughout.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 319b965f9f19afc4421639a66de21f1818ceddde
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon May 9 16:13:18 2022 +0200

    random: remove ratelimiting for in-kernel unseeded randomness
    
    commit cc1e127bfa95b5fb2f9307e7168bf8b2b45b4c5e upstream.
    
    The CONFIG_WARN_ALL_UNSEEDED_RANDOM debug option controls whether the
    kernel warns about all unseeded randomness or just the first instance.
    There's some complicated rate limiting and comparison to the previous
    caller, such that even with CONFIG_WARN_ALL_UNSEEDED_RANDOM enabled,
    developers still don't see all the messages or even an accurate count of
    how many were missed. This is the result of basically parallel
    mechanisms aimed at accomplishing more or less the same thing, added at
    different points in random.c history, which sort of compete with the
    first-instance-only limiting we have now.
    
    It turns out, however, that nobody cares about the first unseeded
    randomness instance of in-kernel users. The same first user has been
    there for ages now, and nobody is doing anything about it. It isn't even
    clear that anybody _can_ do anything about it. Most places that can do
    something about it have switched over to using get_random_bytes_wait()
    or wait_for_random_bytes(), which is the right thing to do, but there is
    still much code that needs randomness sometimes during init, and as a
    geeneral rule, if you're not using one of the _wait functions or the
    readiness notifier callback, you're bound to be doing it wrong just
    based on that fact alone.
    
    So warning about this same first user that can't easily change is simply
    not an effective mechanism for anything at all. Users can't do anything
    about it, as the Kconfig text points out -- the problem isn't in
    userspace code -- and kernel developers don't or more often can't react
    to it.
    
    Instead, show the warning for all instances when CONFIG_WARN_ALL_UNSEEDED_RANDOM
    is set, so that developers can debug things need be, or if it isn't set,
    don't show a warning at all.
    
    At the same time, CONFIG_WARN_ALL_UNSEEDED_RANDOM now implies setting
    random.ratelimit_disable=1 on by default, since if you care about one
    you probably care about the other too. And we can clean up usage around
    the related urandom_warning ratelimiter as well (whose behavior isn't
    changing), so that it properly counts missed messages after the 10
    message threshold is reached.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0251a5fd3c69a0c56ce5a79c27aa3330a611621c
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon May 9 13:40:55 2022 +0200

    random: avoid initializing twice in credit race
    
    commit fed7ef061686cc813b1f3d8d0edc6c35b4d3537b upstream.
    
    Since all changes of crng_init now go through credit_init_bits(), we can
    fix a long standing race in which two concurrent callers of
    credit_init_bits() have the new bit count >= some threshold, but are
    doing so with crng_init as a lower threshold, checked outside of a lock,
    resulting in crng_reseed() or similar being called twice.
    
    In order to fix this, we can use the original cmpxchg value of the bit
    count, and only change crng_init when the bit count transitions from
    below a threshold to meeting the threshold.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ddc38d39e7f98a86d913906eee530bec756453c
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun May 8 13:20:30 2022 +0200

    random: use symbolic constants for crng_init states
    
    commit e3d2c5e79a999aa4e7d6f0127e16d3da5a4ff70d upstream.
    
    crng_init represents a state machine, with three states, and various
    rules for transitions. For the longest time, we've been managing these
    with "0", "1", and "2", and expecting people to figure it out. To make
    the code more obvious, replace these with proper enum values
    representing the transition, and then redocument what each of these
    states mean.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Joe Perches <joe@perches.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66b2dde034bdc7bdb2de1b868deb0b3d5aa51a69
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat May 7 14:03:46 2022 +0200

    siphash: use one source of truth for siphash permutations
    
    commit e73aaae2fa9024832e1f42e30c787c7baf61d014 upstream.
    
    The SipHash family of permutations is currently used in three places:
    
    - siphash.c itself, used in the ordinary way it was intended.
    - random32.c, in a construction from an anonymous contributor.
    - random.c, as part of its fast_mix function.
    
    Each one of these places reinvents the wheel with the same C code, same
    rotation constants, and same symmetry-breaking constants.
    
    This commit tidies things up a bit by placing macros for the
    permutations and constants into siphash.h, where each of the three .c
    users can access them. It also leaves a note dissuading more users of
    them from emerging.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb2fb9672be8334f828e732fe4b98e06f4ba03c5
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 6 23:19:43 2022 +0200

    random: help compiler out with fast_mix() by using simpler arguments
    
    commit 791332b3cbb080510954a4c152ce02af8832eac9 upstream.
    
    Now that fast_mix() has more than one caller, gcc no longer inlines it.
    That's fine. But it also doesn't handle the compound literal argument we
    pass it very efficiently, nor does it handle the loop as well as it
    could. So just expand the code to spell out this function so that it
    generates the same code as it did before. Performance-wise, this now
    behaves as it did before the last commit. The difference in actual code
    size on x86 is 45 bytes, which is less than a cache line.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18aa432eb1e04c9470df8ffa92d6bb290ecbc40e
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 6 18:30:51 2022 +0200

    random: do not use input pool from hard IRQs
    
    commit e3e33fc2ea7fcefd0d761db9d6219f83b4248f5c upstream.
    
    Years ago, a separate fast pool was added for interrupts, so that the
    cost associated with taking the input pool spinlocks and mixing into it
    would be avoided in places where latency is critical. However, one
    oversight was that add_input_randomness() and add_disk_randomness()
    still sometimes are called directly from the interrupt handler, rather
    than being deferred to a thread. This means that some unlucky interrupts
    will be caught doing a blake2s_compress() call and potentially spinning
    on input_pool.lock, which can also be taken by unprivileged users by
    writing into /dev/urandom.
    
    In order to fix this, add_timer_randomness() now checks whether it is
    being called from a hard IRQ and if so, just mixes into the per-cpu IRQ
    fast pool using fast_mix(), which is much faster and can be done
    lock-free. A nice consequence of this, as well, is that it means hard
    IRQ context FPU support is likely no longer useful.
    
    The entropy estimation algorithm used by add_timer_randomness() is also
    somewhat different than the one used for add_interrupt_randomness(). The
    former looks at deltas of deltas of deltas, while the latter just waits
    for 64 interrupts for one bit or for one second since the last bit. In
    order to bridge these, and since add_interrupt_randomness() runs after
    an add_timer_randomness() that's called from hard IRQ, we add to the
    fast pool credit the related amount, and then subtract one to account
    for add_interrupt_randomness()'s contribution.
    
    A downside of this, however, is that the num argument is potentially
    attacker controlled, which puts a bit more pressure on the fast_mix()
    sponge to do more than it's really intended to do. As a mitigating
    factor, the first 96 bits of input aren't attacker controlled (a cycle
    counter followed by zeros), which means it's essentially two rounds of
    siphash rather than one, which is somewhat better. It's also not that
    much different from add_interrupt_randomness()'s use of the irq stack
    instruction pointer register.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Filipe Manana <fdmanana@suse.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4728fd103dedbe060b525437cfb886b48149847
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 6 18:27:38 2022 +0200

    random: order timer entropy functions below interrupt functions
    
    commit a4b5c26b79ffdfcfb816c198f2fc2b1e7b5b580f upstream.
    
    There are no code changes here; this is just a reordering of functions,
    so that in subsequent commits, the timer entropy functions can call into
    the interrupt ones.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71db23726a7738168cc9e8a314b21fa314f91bd7
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 30 22:03:29 2022 +0200

    random: do not pretend to handle premature next security model
    
    commit e85c0fc1d94c52483a603651748d4c76d6aa1c6b upstream.
    
    Per the thread linked below, "premature next" is not considered to be a
    realistic threat model, and leads to more serious security problems.
    
    "Premature next" is the scenario in which:
    
    - Attacker compromises the current state of a fully initialized RNG via
      some kind of infoleak.
    - New bits of entropy are added directly to the key used to generate the
      /dev/urandom stream, without any buffering or pooling.
    - Attacker then, somehow having read access to /dev/urandom, samples RNG
      output and brute forces the individual new bits that were added.
    - Result: the RNG never "recovers" from the initial compromise, a
      so-called violation of what academics term "post-compromise security".
    
    The usual solutions to this involve some form of delaying when entropy
    gets mixed into the crng. With Fortuna, this involves multiple input
    buckets. With what the Linux RNG was trying to do prior, this involves
    entropy estimation.
    
    However, by delaying when entropy gets mixed in, it also means that RNG
    compromises are extremely dangerous during the window of time before
    the RNG has gathered enough entropy, during which time nonces may become
    predictable (or repeated), ephemeral keys may not be secret, and so
    forth. Moreover, it's unclear how realistic "premature next" is from an
    attack perspective, if these attacks even make sense in practice.
    
    Put together -- and discussed in more detail in the thread below --
    these constitute grounds for just doing away with the current code that
    pretends to handle premature next. I say "pretends" because it wasn't
    doing an especially great job at it either; should we change our mind
    about this direction, we would probably implement Fortuna to "fix" the
    "problem", in which case, removing the pretend solution still makes
    sense.
    
    This also reduces the crng reseed period from 5 minutes down to 1
    minute. The rationale from the thread might lead us toward reducing that
    even further in the future (or even eliminating it), but that remains a
    topic of a future commit.
    
    At a high level, this patch changes semantics from:
    
        Before: Seed for the first time after 256 "bits" of estimated
        entropy have been accumulated since the system booted. Thereafter,
        reseed once every five minutes, but only if 256 new "bits" have been
        accumulated since the last reseeding.
    
        After: Seed for the first time after 256 "bits" of estimated entropy
        have been accumulated since the system booted. Thereafter, reseed
        once every minute.
    
    Most of this patch is renaming and removing: POOL_MIN_BITS becomes
    POOL_INIT_BITS, credit_entropy_bits() becomes credit_init_bits(),
    crng_reseed() loses its "force" parameter since it's now always true,
    the drain_entropy() function no longer has any use so it's removed,
    entropy estimation is skipped if we've already init'd, the various
    notifiers for "low on entropy" are now only active prior to init, and
    finally, some documentation comments are cleaned up here and there.
    
    Link: https://lore.kernel.org/lkml/YmlMGx6+uigkGiZ0@zx2c4.com/
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Nadia Heninger <nadiah@cs.ucsd.edu>
    Cc: Tom Ristenpart <ristenpart@cornell.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fed6de0e0bac9d446de80b4734820c4b16c2abe9
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue May 3 14:14:32 2022 +0200

    random: do not use batches when !crng_ready()
    
    commit cbe89e5a375a51bbb952929b93fa973416fea74e upstream.
    
    It's too hard to keep the batches synchronized, and pointless anyway,
    since in !crng_ready(), we're updating the base_crng key really often,
    where batching only hurts. So instead, if the crng isn't ready, just
    call into get_random_bytes(). At this stage nothing is performance
    critical anyhow.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70cf7fb6d379ece8af3326257fa55e5ab18a16d9
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Apr 12 19:59:57 2022 +0200

    random: insist on random_get_entropy() existing in order to simplify
    
    commit 4b758eda851eb9336ca86a0041a4d3da55f66511 upstream.
    
    All platforms are now guaranteed to provide some value for
    random_get_entropy(). In case some bug leads to this not being so, we
    print a warning, because that indicates that something is really very
    wrong (and likely other things are impacted too). This should never be
    hit, but it's a good and cheap way of finding out if something ever is
    problematic.
    
    Since we now have viable fallback code for random_get_entropy() on all
    platforms, which is, in the worst case, not worse than jiffies, we can
    count on getting the best possible value out of it. That means there's
    no longer a use for using jiffies as entropy input. It also means we no
    longer have a reason for doing the round-robin register flow in the IRQ
    handler, which was always of fairly dubious value.
    
    Instead we can greatly simplify the IRQ handler inputs and also unify
    the construction between 64-bits and 32-bits. We now collect the cycle
    counter and the return address, since those are the two things that
    matter. Because the return address and the irq number are likely
    related, to the extent we mix in the irq number, we can just xor it into
    the top unchanging bytes of the return address, rather than the bottom
    changing bytes of the cycle counter as before. Then, we can do a fixed 2
    rounds of SipHash/HSipHash. Finally, we use the same construction of
    hashing only half of the [H]SipHash state on 32-bit and 64-bit. We're
    not actually discarding any entropy, since that entropy is carried
    through until the next time. And more importantly, it lets us do the
    same sponge-like construction everywhere.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf8717e15a9e2f0c50409d9c491df735f6a7f75b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    xtensa: use fallback for random_get_entropy() instead of zero
    
    commit e10e2f58030c5c211d49042a8c2a1b93d40b2ffb upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is really not the best we can do.
    Instead, at least calling random_get_entropy_fallback() would be
    preferable, because that always needs to return _something_, even
    falling back to jiffies eventually. It's not as though
    random_get_entropy_fallback() is super high precision or guaranteed to
    be entropic, but basically anything that's not zero all the time is
    better than returning zero all the time.
    
    This is accomplished by just including the asm-generic code like on
    other architectures, which means we can get rid of the empty stub
    function here.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac7fbc3df2ed96bbe1c64e561f538f374433d6c1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    sparc: use fallback for random_get_entropy() instead of zero
    
    commit ac9756c79797bb98972736b13cfb239fd2cffb79 upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is really not the best we can do.
    Instead, at least calling random_get_entropy_fallback() would be
    preferable, because that always needs to return _something_, even
    falling back to jiffies eventually. It's not as though
    random_get_entropy_fallback() is super high precision or guaranteed to
    be entropic, but basically anything that's not zero all the time is
    better than returning zero all the time.
    
    This is accomplished by just including the asm-generic code like on
    other architectures, which means we can get rid of the empty stub
    function here.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d78483f5fe85ce32d5614e8746ab5b34838122d1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    um: use fallback for random_get_entropy() instead of zero
    
    commit 9f13fb0cd11ed2327abff69f6501a2c124c88b5a upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is really not the best we can do.
    Instead, at least calling random_get_entropy_fallback() would be
    preferable, because that always needs to return _something_, even
    falling back to jiffies eventually. It's not as though
    random_get_entropy_fallback() is super high precision or guaranteed to
    be entropic, but basically anything that's not zero all the time is
    better than returning zero all the time.
    
    This is accomplished by just including the asm-generic code like on
    other architectures, which means we can get rid of the empty stub
    function here.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4373bcb96fcc5b961037e06b1e903fc92943ed94
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    x86/tsc: Use fallback for random_get_entropy() instead of zero
    
    commit 3bd4abc07a267e6a8b33d7f8717136e18f921c53 upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is suboptimal. Instead, fallback
    to calling random_get_entropy_fallback(), which isn't extremely high
    precision or guaranteed to be entropic, but is certainly better than
    returning zero all the time.
    
    If CONFIG_X86_TSC=n, then it's possible for the kernel to run on systems
    without RDTSC, such as 486 and certain 586, so the fallback code is only
    required for that case.
    
    As well, fix up both the new function and the get_cycles() function from
    which it was derived to use cpu_feature_enabled() rather than
    boot_cpu_has(), and use !IS_ENABLED() instead of #ifndef.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: x86@kernel.org
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f869f2e72e81e1fce3f8bf2626c4226fe959dcb4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    nios2: use fallback for random_get_entropy() instead of zero
    
    commit c04e72700f2293013dab40208e809369378f224c upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is really not the best we can do.
    Instead, at least calling random_get_entropy_fallback() would be
    preferable, because that always needs to return _something_, even
    falling back to jiffies eventually. It's not as though
    random_get_entropy_fallback() is super high precision or guaranteed to
    be entropic, but basically anything that's not zero all the time is
    better than returning zero all the time.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7605b265200950e09816d6261c5ff0cdb12e7e28
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    arm: use fallback for random_get_entropy() instead of zero
    
    commit ff8a8f59c99f6a7c656387addc4d9f2247d75077 upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is really not the best we can do.
    Instead, at least calling random_get_entropy_fallback() would be
    preferable, because that always needs to return _something_, even
    falling back to jiffies eventually. It's not as though
    random_get_entropy_fallback() is super high precision or guaranteed to
    be entropic, but basically anything that's not zero all the time is
    better than returning zero all the time.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abb6b7e172e91ad9e1e3bc538e52b0d9e70d1002
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    mips: use fallback for random_get_entropy() instead of just c0 random
    
    commit 1c99c6a7c3c599a68321b01b9ec243215ede5a68 upstream.
    
    For situations in which we don't have a c0 counter register available,
    we've been falling back to reading the c0 "random" register, which is
    usually bounded by the amount of TLB entries and changes every other
    cycle or so. This means it wraps extremely often. We can do better by
    combining this fast-changing counter with a potentially slower-changing
    counter from random_get_entropy_fallback() in the more significant bits.
    This commit combines the two, taking into account that the changing bits
    are in a different bit position depending on the CPU model. In addition,
    we previously were falling back to 0 for ancient CPUs that Linux does
    not support anyway; remove that dead path entirely.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Tested-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63959c5833eca56b97b42d3ecb42c494c78787a2
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:03:13 2022 +0200

    m68k: use fallback for random_get_entropy() instead of zero
    
    commit 0f392c95391f2d708b12971a07edaa7973f9eece upstream.
    
    In the event that random_get_entropy() can't access a cycle counter or
    similar, falling back to returning 0 is really not the best we can do.
    Instead, at least calling random_get_entropy_fallback() would be
    preferable, because that always needs to return _something_, even
    falling back to jiffies eventually. It's not as though
    random_get_entropy_fallback() is super high precision or guaranteed to
    be entropic, but basically anything that's not zero all the time is
    better than returning zero all the time.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2142a4d898519736aea596e4f1d9a1062edb20c7
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Apr 10 16:49:50 2022 +0200

    timekeeping: Add raw clock fallback for random_get_entropy()
    
    commit 1366992e16bddd5e2d9a561687f367f9f802e2e4 upstream.
    
    The addition of random_get_entropy_fallback() provides access to
    whichever time source has the highest frequency, which is useful for
    gathering entropy on platforms without available cycle counters. It's
    not necessarily as good as being able to quickly access a cycle counter
    that the CPU has, but it's still something, even when it falls back to
    being jiffies-based.
    
    In the event that a given arch does not define get_cycles(), falling
    back to the get_cycles() default implementation that returns 0 is really
    not the best we can do. Instead, at least calling
    random_get_entropy_fallback() would be preferable, because that always
    needs to return _something_, even falling back to jiffies eventually.
    It's not as though random_get_entropy_fallback() is super high precision
    or guaranteed to be entropic, but basically anything that's not zero all
    the time is better than returning zero all the time.
    
    Finally, since random_get_entropy_fallback() is used during extremely
    early boot when randomizing freelists in mm_init(), it can be called
    before timekeeping has been initialized. In that case there really is
    nothing we can do; jiffies hasn't even started ticking yet. So just give
    up and return 0.
    
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a182df6e951b381f23ff2a0a9506de9dbf2e29b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 23 21:11:41 2022 +0200

    powerpc: define get_cycles macro for arch-override
    
    commit 408835832158df0357e18e96da7f2d1ed6b80e7f upstream.
    
    PowerPC defines a get_cycles() function, but it does not do the usual
    `#define get_cycles get_cycles` dance, making it impossible for generic
    code to see if an arch-specific function was defined. While the
    get_cycles() ifdef is not currently used, the following timekeeping
    patch in this series will depend on the macro existing (or not existing)
    when defining random_get_entropy().
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Benjamin Herrenschmidt <benh@ozlabs.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d969c9880bafd6e4986f125720da8b238a1aadd1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 23 21:11:41 2022 +0200

    alpha: define get_cycles macro for arch-override
    
    commit 1097710bc9660e1e588cf2186a35db3d95c4d258 upstream.
    
    Alpha defines a get_cycles() function, but it does not do the usual
    `#define get_cycles get_cycles` dance, making it impossible for generic
    code to see if an arch-specific function was defined. While the
    get_cycles() ifdef is not currently used, the following timekeeping
    patch in this series will depend on the macro existing (or not existing)
    when defining random_get_entropy().
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Acked-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit faf62b743975f623677ec0f59cb2f2f750cd35d1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 23 21:11:41 2022 +0200

    parisc: define get_cycles macro for arch-override
    
    commit 8865bbe6ba1120e67f72201b7003a16202cd42be upstream.
    
    PA-RISC defines a get_cycles() function, but it does not do the usual
    `#define get_cycles get_cycles` dance, making it impossible for generic
    code to see if an arch-specific function was defined. While the
    get_cycles() ifdef is not currently used, the following timekeeping
    patch in this series will depend on the macro existing (or not existing)
    when defining random_get_entropy().
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0da28452ba041054b4281f34db877d737f3fec13
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 23 21:11:41 2022 +0200

    s390: define get_cycles macro for arch-override
    
    commit 2e3df523256cb9836de8441e9c791a796759bb3c upstream.
    
    S390x defines a get_cycles() function, but it does not do the usual
    `#define get_cycles get_cycles` dance, making it impossible for generic
    code to see if an arch-specific function was defined. While the
    get_cycles() ifdef is not currently used, the following timekeeping
    patch in this series will depend on the macro existing (or not existing)
    when defining random_get_entropy().
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Alexander Gordeev <agordeev@linux.ibm.com>
    Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
    Cc: Sven Schnelle <svens@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e154c03c323e29f56fb46751fb7abee924b47347
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 23 21:11:41 2022 +0200

    ia64: define get_cycles macro for arch-override
    
    commit 57c0900b91d8891ab43f0e6b464d059fda51d102 upstream.
    
    Itanium defines a get_cycles() function, but it does not do the usual
    `#define get_cycles get_cycles` dance, making it impossible for generic
    code to see if an arch-specific function was defined. While the
    get_cycles() ifdef is not currently used, the following timekeeping
    patch in this series will depend on the macro existing (or not existing)
    when defining random_get_entropy().
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4798c86f1b70e391acddc532bbac0a243e014c4c
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu May 5 02:20:22 2022 +0200

    init: call time_init() before rand_initialize()
    
    commit fe222a6ca2d53c38433cba5d3be62a39099e708e upstream.
    
    Currently time_init() is called after rand_initialize(), but
    rand_initialize() makes use of the timer on various platforms, and
    sometimes this timer needs to be initialized by time_init() first. In
    order for random_get_entropy() to not return zero during early boot when
    it's potentially used as an entropy source, reverse the order of these
    two calls. The block doing random initialization was right before
    time_init() before, so changing the order shouldn't have any complicated
    effects.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70e65f65f248961d573905a5cf6c88c5983681aa
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue May 3 21:43:58 2022 +0200

    random: fix sysctl documentation nits
    
    commit 069c4ea6871c18bd368f27756e0f91ffb524a788 upstream.
    
    A semicolon was missing, and the almost-alphabetical-but-not ordering
    was confusing, so regroup these by category instead.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8005202686bd853b53c5008f3e13227c1b80f7d2
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Apr 18 20:57:31 2022 +0200

    random: document crng_fast_key_erasure() destination possibility
    
    commit 8717627d6ac53251ee012c3c7aca392f29f38a42 upstream.
    
    This reverts 35a33ff3807d ("random: use memmove instead of memcpy for
    remaining 32 bytes"), which was made on a totally bogus basis. The thing
    it was worried about overlapping came from the stack, not from one of
    its arguments, as Eric pointed out.
    
    But the fact that this confusion even happened draws attention to the
    fact that it's a bit non-obvious that the random_data parameter can
    alias chacha_state, and in fact should do so when the caller can't rely
    on the stack being cleared in a timely manner. So this commit documents
    that.
    
    Reported-by: Eric Biggers <ebiggers@kernel.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fab8d784338f7d587d29865b14eddfa55bd4d99
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Apr 8 18:14:57 2022 +0200

    random: make random_get_entropy() return an unsigned long
    
    commit b0c3e796f24b588b862b61ce235d3c9417dc8983 upstream.
    
    Some implementations were returning type `unsigned long`, while others
    that fell back to get_cycles() were implicitly returning a `cycles_t` or
    an untyped constant int literal. That makes for weird and confusing
    code, and basically all code in the kernel already handled it like it
    was an `unsigned long`. I recently tried to handle it as the largest
    type it could be, a `cycles_t`, but doing so doesn't really help with
    much.
    
    Instead let's just make random_get_entropy() return an unsigned long all
    the time. This also matches the commonly used `arch_get_random_long()`
    function, so now RDRAND and RDTSC return the same sized integer, which
    means one can fallback to the other more gracefully.
    
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50339a2aab7e0104e356523be0a450ab3d24a33a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Apr 6 02:36:16 2022 +0200

    random: check for signals every PAGE_SIZE chunk of /dev/[u]random
    
    commit e3c1c4fd9e6d14059ed93ebfe15e1c57793b1a05 upstream.
    
    In 1448769c9cdb ("random: check for signal_pending() outside of
    need_resched() check"), Jann pointed out that we previously were only
    checking the TIF_NOTIFY_SIGNAL and TIF_SIGPENDING flags if the process
    had TIF_NEED_RESCHED set, which meant in practice, super long reads to
    /dev/[u]random would delay signal handling by a long time. I tried this
    using the below program, and indeed I wasn't able to interrupt a
    /dev/urandom read until after several megabytes had been read. The bug
    he fixed has always been there, and so code that reads from /dev/urandom
    without checking the return value of read() has mostly worked for a long
    time, for most sizes, not just for <= 256.
    
    Maybe it makes sense to keep that code working. The reason it was so
    small prior, ignoring the fact that it didn't work anyway, was likely
    because /dev/random used to block, and that could happen for pretty
    large lengths of time while entropy was gathered. But now, it's just a
    chacha20 call, which is extremely fast and is just operating on pure
    data, without having to wait for some external event. In that sense,
    /dev/[u]random is a lot more like /dev/zero.
    
    Taking a page out of /dev/zero's read_zero() function, it always returns
    at least one chunk, and then checks for signals after each chunk. Chunk
    sizes there are of length PAGE_SIZE. Let's just copy the same thing for
    /dev/[u]random, and check for signals and cond_resched() for every
    PAGE_SIZE amount of data. This makes the behavior more consistent with
    expectations, and should mitigate the impact of Jann's fix for the
    age-old signal check bug.
    
    ---- test program ----
    
      #include <unistd.h>
      #include <signal.h>
      #include <stdio.h>
      #include <sys/random.h>
    
      static unsigned char x[~0U];
    
      static void handle(int) { }
    
      int main(int argc, char *argv[])
      {
        pid_t pid = getpid(), child;
        signal(SIGUSR1, handle);
        if (!(child = fork())) {
          for (;;)
            kill(pid, SIGUSR1);
        }
        pause();
        printf("interrupted after reading %zd bytes\n", getrandom(x, sizeof(x), 0));
        kill(child, SIGTERM);
        return 0;
      }
    
    Cc: Jann Horn <jannh@google.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf8136b351692783036bc4eb0df85ebaf453d8b5
Author: Jann Horn <jannh@google.com>
Date:   Tue Apr 5 18:39:31 2022 +0200

    random: check for signal_pending() outside of need_resched() check
    
    commit 1448769c9cdb69ad65287f4f7ab58bc5f2f5d7ba upstream.
    
    signal_pending() checks TIF_NOTIFY_SIGNAL and TIF_SIGPENDING, which
    signal that the task should bail out of the syscall when possible. This
    is a separate concept from need_resched(), which checks
    TIF_NEED_RESCHED, signaling that the task should preempt.
    
    In particular, with the current code, the signal_pending() bailout
    probably won't work reliably.
    
    Change this to look like other functions that read lots of data, such as
    read_zero().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04d681d81b7dfbfc5f33094914de96e2e047f22f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Apr 5 16:40:51 2022 +0200

    random: do not allow user to keep crng key around on stack
    
    commit aba120cc101788544aa3e2c30c8da88513892350 upstream.
    
    The fast key erasure RNG design relies on the key that's used to be used
    and then discarded. We do this, making judicious use of
    memzero_explicit().  However, reads to /dev/urandom and calls to
    getrandom() involve a copy_to_user(), and userspace can use FUSE or
    userfaultfd, or make a massive call, dynamically remap memory addresses
    as it goes, and set the process priority to idle, in order to keep a
    kernel stack alive indefinitely. By probing
    /proc/sys/kernel/random/entropy_avail to learn when the crng key is
    refreshed, a malicious userspace could mount this attack every 5 minutes
    thereafter, breaking the crng's forward secrecy.
    
    In order to fix this, we just overwrite the stack's key with the first
    32 bytes of the "free" fast key erasure output. If we're returning <= 32
    bytes to the user, then we can still return those bytes directly, so
    that short reads don't become slower. And for long reads, the difference
    is hopefully lost in the amortization, so it doesn't change much, with
    that amortization helping variously for medium reads.
    
    We don't need to do this for get_random_bytes() and the various
    kernel-space callers, and later, if we ever switch to always batching,
    this won't be necessary either, so there's no need to change the API of
    these functions.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jann Horn <jannh@google.com>
    Fixes: c92e040d575a ("random: add backtracking protection to the CRNG")
    Fixes: 186873c549df ("random: use simpler fast key erasure flow on per-cpu keys")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a4646c15d4fbf2afaea29bbbafaf48b8554034e
Author: Jan Varho <jan.varho@gmail.com>
Date:   Mon Apr 4 19:42:30 2022 +0300

    random: do not split fast init input in add_hwgenerator_randomness()
    
    commit 527a9867af29ff89f278d037db704e0ed50fb666 upstream.
    
    add_hwgenerator_randomness() tries to only use the required amount of input
    for fast init, but credits all the entropy, rather than a fraction of
    it. Since it's hard to determine how much entropy is left over out of a
    non-unformly random sample, either give it all to fast init or credit
    it, but don't attempt to do both. In the process, we can clean up the
    injection code to no longer need to return a value.
    
    Signed-off-by: Jan Varho <jan.varho@gmail.com>
    [Jason: expanded commit message]
    Fixes: 73c7733f122e ("random: do not throw away excess input to crng_fast_load")
    Cc: stable@vger.kernel.org # 5.17+, requires af704c856e88
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bba3aac2241f5f3792c405e5a01e7a9fdbc5e249
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Mar 31 11:01:01 2022 -0400

    random: mix build-time latent entropy into pool at init
    
    commit 1754abb3e7583c570666fa1e1ee5b317e88c89a0 upstream.
    
    Prior, the "input_pool_data" array needed no real initialization, and so
    it was easy to mark it with __latent_entropy to populate it during
    compile-time. In switching to using a hash function, this required us to
    specifically initialize it to some specific state, which means we
    dropped the __latent_entropy attribute. An unfortunate side effect was
    this meant the pool was no longer seeded using compile-time random data.
    In order to bring this back, we declare an array in rand_initialize()
    with __latent_entropy and call mix_pool_bytes() on that at init, which
    accomplishes the same thing as before. We make this __initconst, so that
    it doesn't take up space at runtime after init.
    
    Fixes: 6e8ec2552c7d ("random: use computational hash for entropy extraction")
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd852448d59e95c913abeb5b95e060a1003e87c9
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Mar 22 22:21:52 2022 -0600

    random: re-add removed comment about get_random_{u32,u64} reseeding
    
    commit dd7aa36e535797926d8eb311da7151919130139d upstream.
    
    The comment about get_random_{u32,u64}() not invoking reseeding got
    added in an unrelated commit, that then was recently reverted by
    0313bc278dac ("Revert "random: block in /dev/urandom""). So this adds
    that little comment snippet back, and improves the wording a bit too.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eed01a6b3e563bcc6cbe27ab046dc3cd46febd22
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Mar 22 21:43:12 2022 -0600

    random: treat bootloader trust toggle the same way as cpu trust toggle
    
    commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream.
    
    If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND.
    But, the user can disable (or enable) this behavior by setting
    `random.trust_cpu=0/1` on the kernel command line. This allows system
    builders to do reasonable things while avoiding howls from tinfoil
    hatters. (Or vice versa.)
    
    CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards
    the seed passed via EFI or device tree, which might come from RDRAND or
    a TPM or somewhere else. In order to allow distros to more easily enable
    this while avoiding those same howls (or vice versa), this commit adds
    the corresponding `random.trust_bootloader=0/1` toggle.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Graham Christensen <graham@grahamc.com>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Link: https://github.com/NixOS/nixpkgs/pull/165355
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df5104c1d0b6a602d5030fadf0249df4c302b9d7
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Mar 21 18:48:05 2022 -0600

    random: skip fast_init if hwrng provides large chunk of entropy
    
    commit af704c856e888fb044b058d731d61b46eeec499d upstream.
    
    At boot time, EFI calls add_bootloader_randomness(), which in turn calls
    add_hwgenerator_randomness(). Currently add_hwgenerator_randomness()
    feeds the first 64 bytes of randomness to the "fast init"
    non-crypto-grade phase. But if add_hwgenerator_randomness() gets called
    with more than POOL_MIN_BITS of entropy, there's no point in passing it
    off to the "fast init" stage, since that's enough entropy to bootstrap
    the real RNG. The "fast init" stage is just there to provide _something_
    in the case where we don't have enough entropy to properly bootstrap the
    RNG. But if we do have enough entropy to bootstrap the RNG, the current
    logic doesn't serve a purpose. So, in the case where we're passed
    greater than or equal to POOL_MIN_BITS of entropy, this commit makes us
    skip the "fast init" phase.
    
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e7ef351ea331595e12f94332180ed551f26cd36
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Mar 8 10:12:16 2022 -0700

    random: check for signal and try earlier when generating entropy
    
    commit 3e504d2026eb6c8762cd6040ae57db166516824a upstream.
    
    Rather than waiting a full second in an interruptable waiter before
    trying to generate entropy, try to generate entropy first and wait
    second. While waiting one second might give an extra second for getting
    entropy from elsewhere, we're already pretty late in the init process
    here, and whatever else is generating entropy will still continue to
    contribute. This has implications on signal handling: we call
    try_to_generate_entropy() from wait_for_random_bytes(), and
    wait_for_random_bytes() always uses wait_event_interruptible_timeout()
    when waiting, since it's called by userspace code in restartable
    contexts, where signals can pend. Since try_to_generate_entropy() now
    runs first, if a signal is pending, it's necessary for
    try_to_generate_entropy() to check for signals, since it won't hit the
    wait until after try_to_generate_entropy() has returned. And even before
    this change, when entering a busy loop in try_to_generate_entropy(), we
    should have been checking to see if any signals are pending, so that a
    process doesn't get stuck in that loop longer than expected.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 052377053c31941f79ab6a1f9ef65af601556db4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Mar 8 23:32:34 2022 -0700

    random: reseed more often immediately after booting
    
    commit 7a7ff644aeaf071d433caffb3b8ea57354b55bd3 upstream.
    
    In order to chip away at the "premature first" problem, we augment our
    existing entropy accounting with more frequent reseedings at boot.
    
    The idea is that at boot, we're getting entropy from various places, and
    we're not very sure which of early boot entropy is good and which isn't.
    Even when we're crediting the entropy, we're still not totally certain
    that it's any good. Since boot is the one time (aside from a compromise)
    that we have zero entropy, it's important that we shepherd entropy into
    the crng fairly often.
    
    At the same time, we don't want a "premature next" problem, whereby an
    attacker can brute force individual bits of added entropy. In lieu of
    going full-on Fortuna (for now), we can pick a simpler strategy of just
    reseeding more often during the first 5 minutes after boot. This is
    still bounded by the 256-bit entropy credit requirement, so we'll skip a
    reseeding if we haven't reached that, but in case entropy /is/ coming
    in, this ensures that it makes its way into the crng rather rapidly
    during these early stages.
    
    Ordinarily we reseed if the previous reseeding is 300 seconds old. This
    commit changes things so that for the first 600 seconds of boot time, we
    reseed if the previous reseeding is uptime / 2 seconds old. That means
    that we'll reseed at the very least double the uptime of the previous
    reseeding.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f629607339682920ffdd3146453dbacb2f56a163
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Mar 8 11:20:17 2022 -0700

    random: make consistent usage of crng_ready()
    
    commit a96cfe2d427064325ecbf56df8816c6b871ec285 upstream.
    
    Rather than sometimes checking `crng_init < 2`, we should always use the
    crng_ready() macro, so that should we change anything later, it's
    consistent. Additionally, that macro already has a likely() around it,
    which means we don't need to open code our own likely() and unlikely()
    annotations.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9a694a92c2105b80623d84c0d03a030b787d29a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 14:58:44 2022 +0100

    random: use SipHash as interrupt entropy accumulator
    
    commit f5eab0e2db4f881fb2b62b3fdad5b9be673dd7ae upstream.
    
    The current fast_mix() function is a piece of classic mailing list
    crypto, where it just sort of sprung up by an anonymous author without a
    lot of real analysis of what precisely it was accomplishing. As an ARX
    permutation alone, there are some easily searchable differential trails
    in it, and as a means of preventing malicious interrupts, it completely
    fails, since it xors new data into the entire state every time. It can't
    really be analyzed as a random permutation, because it clearly isn't,
    and it can't be analyzed as an interesting linear algebraic structure
    either, because it's also not that. There really is very little one can
    say about it in terms of entropy accumulation. It might diffuse bits,
    some of the time, maybe, we hope, I guess. But for the most part, it
    fails to accomplish anything concrete.
    
    As a reminder, the simple goal of add_interrupt_randomness() is to
    simply accumulate entropy until ~64 interrupts have elapsed, and then
    dump it into the main input pool, which uses a cryptographic hash.
    
    It would be nice to have something cryptographically strong in the
    interrupt handler itself, in case a malicious interrupt compromises a
    per-cpu fast pool within the 64 interrupts / 1 second window, and then
    inside of that same window somehow can control its return address and
    cycle counter, even if that's a bit far fetched. However, with a very
    CPU-limited budget, actually doing that remains an active research
    project (and perhaps there'll be something useful for Linux to come out
    of it). And while the abundance of caution would be nice, this isn't
    *currently* the security model, and we don't yet have a fast enough
    solution to make it our security model. Plus there's not exactly a
    pressing need to do that. (And for the avoidance of doubt, the actual
    cluster of 64 accumulated interrupts still gets dumped into our
    cryptographically secure input pool.)
    
    So, for now we are going to stick with the existing interrupt security
    model, which assumes that each cluster of 64 interrupt data samples is
    mostly non-malicious and not colluding with an infoleaker. With this as
    our goal, we have a few more choices, simply aiming to accumulate
    entropy, while discarding the least amount of it.
    
    We know from <https://eprint.iacr.org/2019/198> that random oracles,
    instantiated as computational hash functions, make good entropy
    accumulators and extractors, which is the justification for using
    BLAKE2s in the main input pool. As mentioned, we don't have that luxury
    here, but we also don't have the same security model requirements,
    because we're assuming that there aren't malicious inputs. A
    pseudorandom function instance can approximately behave like a random
    oracle, provided that the key is uniformly random. But since we're not
    concerned with malicious inputs, we can pick a fixed key, which is not
    secret, knowing that "nature" won't interact with a sufficiently chosen
    fixed key by accident. So we pick a PRF with a fixed initial key, and
    accumulate into it continuously, dumping the result every 64 interrupts
    into our cryptographically secure input pool.
    
    For this, we make use of SipHash-1-x on 64-bit and HalfSipHash-1-x on
    32-bit, which are already in use in the kernel's hsiphash family of
    functions and achieve the same performance as the function they replace.
    It would be nice to do two rounds, but we don't exactly have the CPU
    budget handy for that, and one round alone is already sufficient.
    
    As mentioned, we start with a fixed initial key (zeros is fine), and
    allow SipHash's symmetry breaking constants to turn that into a useful
    starting point. Also, since we're dumping the result (or half of it on
    64-bit so as to tax our hash function the same amount on all platforms)
    into the cryptographically secure input pool, there's no point in
    finalizing SipHash's output, since it'll wind up being finalized by
    something much stronger. This means that all we need to do is use the
    ordinary round function word-by-word, as normal SipHash does.
    Simplified, the flow is as follows:
    
    Initialize:
    
        siphash_state_t state;
        siphash_init(&state, key={0, 0, 0, 0});
    
    Update (accumulate) on interrupt:
    
        siphash_update(&state, interrupt_data_and_timing);
    
    Dump into input pool after 64 interrupts:
    
        blake2s_update(&input_pool, &state, sizeof(state) / 2);
    
    The result of all of this is that the security model is unchanged from
    before -- we assume non-malicious inputs -- yet we now implement that
    model with a stronger argument. I would like to emphasize, again, that
    the purpose of this commit is to improve the existing design, by making
    it analyzable, without changing any fundamental assumptions. There may
    well be value down the road in changing up the existing design, using
    something cryptographically strong, or simply using a ring buffer of
    samples rather than having a fast_mix() at all, or changing which and
    how much data we collect each interrupt so that we can use something
    linear, or a variety of other ideas. This commit does not invalidate the
    potential for those in the future.
    
    For example, in the future, if we're able to characterize the data we're
    collecting on each interrupt, we may be able to inch toward information
    theoretic accumulators. <https://eprint.iacr.org/2021/523> shows that `s
    = ror32(s, 7) ^ x` and `s = ror64(s, 19) ^ x` make very good
    accumulators for 2-monotone distributions, which would apply to
    timestamp counters, like random_get_entropy() or jiffies, but would not
    apply to our current combination of the two values, or to the various
    function addresses and register values we mix in. Alternatively,
    <https://eprint.iacr.org/2021/1002> shows that max-period linear
    functions with no non-trivial invariant subspace make good extractors,
    used in the form `s = f(s) ^ x`. However, this only works if the input
    data is both identical and independent, and obviously a collection of
    address values and counters fails; so it goes with theoretical papers.
    Future directions here may involve trying to characterize more precisely
    what we actually need to collect in the interrupt handler, and building
    something specific around that.
    
    However, as mentioned, the morass of data we're gathering at the
    interrupt handler presently defies characterization, and so we use
    SipHash for now, which works well and performs well.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8e06a4dc297e6d96743e113bbf4804451e9927b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Mar 1 20:03:49 2022 +0100

    random: replace custom notifier chain with standard one
    
    commit 5acd35487dc911541672b3ffc322851769c32a56 upstream.
    
    We previously rolled our own randomness readiness notifier, which only
    has two users in the whole kernel. Replace this with a more standard
    atomic notifier block that serves the same purpose with less code. Also
    unexport the symbols, because no modules use it, only unconditional
    builtins. The only drawback is that it's possible for a notification
    handler returning the "stop" code to prevent further processing, but
    given that there are only two users, and that we're unexporting this
    anyway, that doesn't seem like a significant drawback for the
    simplification we receive here.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    [Jason: for stable, also backported to crypto/drbg.c, not unexporting.]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2c884e41bc5d72ba0bbdd4c5029f223614e616c
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Feb 28 14:00:52 2022 +0100

    random: don't let 644 read-only sysctls be written to
    
    commit 77553cf8f44863b31da242cf24671d76ddb61597 upstream.
    
    We leave around these old sysctls for compatibility, and we keep them
    "writable" for compatibility, but even after writing, we should keep
    reporting the same value. This is consistent with how userspaces tend to
    use sysctl_random_write_wakeup_bits, writing to it, and then later
    reading from it and using the value.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd9970a9e068a0d44da347803c8eb6e4f9a91cb4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Feb 28 13:57:57 2022 +0100

    random: give sysctl_random_min_urandom_seed a more sensible value
    
    commit d0efdf35a6a71d307a250199af6fce122a7c7e11 upstream.
    
    This isn't used by anything or anywhere, but we can't delete it due to
    compatibility. So at least give it the correct value of what it's
    supposed to be instead of a garbage one.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e3d705c7e9ec31e2716cab4d5343e8ceb30029d
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Feb 13 18:25:07 2022 +0100

    random: do crng pre-init loading in worker rather than irq
    
    commit c2a7de4feb6e09f23af7accc0f882a8fa92e7ae5 upstream.
    
    Taking spinlocks from IRQ context is generally problematic for
    PREEMPT_RT. That is, in part, why we take trylocks instead. However, a
    spin_try_lock() is also problematic since another spin_lock() invocation
    can potentially PI-boost the wrong task, as the spin_try_lock() is
    invoked from an IRQ-context, so the task on CPU (random task or idle) is
    not the actual owner.
    
    Additionally, by deferring the crng pre-init loading to the worker, we
    can use the cryptographic hash function rather than xor, which is
    perhaps a meaningful difference when considering this data has only been
    through the relatively weak fast_mix() function.
    
    The biggest downside of this approach is that the pre-init loading is
    now deferred until later, which means things that need random numbers
    after interrupts are enabled, but before workqueues are running -- or
    before this particular worker manages to run -- are going to get into
    trouble. Hopefully in the real world, this window is rather small,
    especially since this code won't run until 64 interrupts had occurred.
    
    Cc: Sultan Alsawaf <sultan@kerneltoast.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Eric Biggers <ebiggers@kernel.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddb672cf1d04dea810e82c59ce6773920ed0333e
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 24 18:30:58 2022 +0100

    random: unify cycles_t and jiffies usage and types
    
    commit abded93ec1e9692920fe309f07f40bd1035f2940 upstream.
    
    random_get_entropy() returns a cycles_t, not an unsigned long, which is
    sometimes 64 bits on various 32-bit platforms, including x86.
    Conversely, jiffies is always unsigned long. This commit fixes things to
    use cycles_t for fields that use random_get_entropy(), named "cycles",
    and unsigned long for fields that use jiffies, named "now". It's also
    good to mix in a cycles_t and a jiffies in the same way for both
    add_device_randomness and add_timer_randomness, rather than using xor in
    one case. Finally, we unify the order of these volatile reads, always
    reading the more precise cycles counter, and then jiffies, so that the
    cycle counter is as close to the event as possible.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55add4d8bc3227bab90dff66301510623268e3bd
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 24 23:04:56 2022 +0100

    random: cleanup UUID handling
    
    commit 64276a9939ff414f2f0db38036cf4e1a0a703394 upstream.
    
    Rather than hard coding various lengths, we can use the right constants.
    Strings should be `char *` while buffers should be `u8 *`. Rather than
    have a nonsensical and unused maxlength, just remove it. Finally, use
    snprintf instead of sprintf, just out of good hygiene.
    
    As well, remove the old comment about returning a binary UUID via the
    binary sysctl syscall. That syscall was removed from the kernel in 5.5,
    and actually, the "uuid_strategy" function and related infrastructure
    for even serving it via the binary sysctl syscall was removed with
    894d2491153a ("sysctl drivers: Remove dead binary sysctl support") back
    in 2.6.33.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 430374f42c2175d0a0f4ff1e24ae9c6b1b74b723
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 22 14:01:57 2022 +0100

    random: only wake up writers after zap if threshold was passed
    
    commit a3f9e8910e1584d7725ef7d5ac870920d42d0bb4 upstream.
    
    The only time that we need to wake up /dev/random writers on
    RNDCLEARPOOL/RNDZAPPOOL is when we're changing from a value that is
    greater than or equal to POOL_MIN_BITS to zero, because if we're
    changing from below POOL_MIN_BITS to zero, the writers are already
    unblocked.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23fc6dcd2935d7f555bbd30a240b6a402ced941d
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 22 13:46:10 2022 +0100

    random: round-robin registers as ulong, not u32
    
    commit da3951ebdcd1cb1d5c750e08cd05aee7b0c04d9a upstream.
    
    When the interrupt handler does not have a valid cycle counter, it calls
    get_reg() to read a register from the irq stack, in round-robin.
    Currently it does this assuming that registers are 32-bit. This is
    _probably_ the case, and probably all platforms without cycle counters
    are in fact 32-bit platforms. But maybe not, and either way, it's not
    quite correct. This commit fixes that to deal with `unsigned long`
    rather than `u32`.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40b5b4b62203c8ea55762604eb11d2fb744da72f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Feb 13 22:48:04 2022 +0100

    random: clear fast pool, crng, and batches in cpuhp bring up
    
    commit 3191dd5a1179ef0fad5a050a1702ae98b6251e8f upstream.
    
    For the irq randomness fast pool, rather than having to use expensive
    atomics, which were visibly the most expensive thing in the entire irq
    handler, simply take care of the extreme edge case of resetting count to
    zero in the cpuhp online handler, just after workqueues have been
    reenabled. This simplifies the code a bit and lets us use vanilla
    variables rather than atomics, and performance should be improved.
    
    As well, very early on when the CPU comes up, while interrupts are still
    disabled, we clear out the per-cpu crng and its batches, so that it
    always starts with fresh randomness.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Sultan Alsawaf <sultan@kerneltoast.com>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57a23e728b087d04ac4991b80941dfc20da5cf5a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Feb 13 16:17:01 2022 +0100

    random: pull add_hwgenerator_randomness() declaration into random.h
    
    commit b777c38239fec5a528e59f55b379e31b1a187524 upstream.
    
    add_hwgenerator_randomness() is a function implemented and documented
    inside of random.c. It is the way that hardware RNGs push data into it.
    Therefore, it should be declared in random.h. Otherwise sparse complains
    with:
    
    random.c:1137:6: warning: symbol 'add_hwgenerator_randomness' was not declared. Should it be static?
    
    The alternative would be to include hw_random.h into random.c, but that
    wouldn't really be good for anything except slowing down compile time.
    
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5357d828bc6abb235121c022fdf3f21e2fb3f12e
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Feb 12 23:57:38 2022 +0100

    random: check for crng_init == 0 in add_device_randomness()
    
    commit 1daf2f387652bf3a7044aea042f5023b3f6b189b upstream.
    
    This has no real functional change, as crng_pre_init_inject() (and
    before that, crng_slow_init()) always checks for == 0, not >= 2. So
    correct the outer unlocked change to reflect that. Before this used
    crng_ready(), which was not correct.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 535d280612b5af4ed7fade95cc9818d7e30b1083
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Feb 12 23:54:09 2022 +0100

    random: unify early init crng load accounting
    
    commit da792c6d5f59a76c10a310c5d4c93428fd18f996 upstream.
    
    crng_fast_load() and crng_slow_load() have different semantics:
    
    - crng_fast_load() xors and accounts with crng_init_cnt.
    - crng_slow_load() hashes and doesn't account.
    
    However add_hwgenerator_randomness() can afford to hash (it's called
    from a kthread), and it should account. Additionally, ones that can
    afford to hash don't need to take a trylock but can take a normal lock.
    So, we combine these into one function, crng_pre_init_inject(), which
    allows us to control these in a uniform way. This will make it simpler
    later to simplify this all down when the time comes for that.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58e0c4ff5342e1962a7464d18568a55a0fc26c9f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Feb 12 01:26:17 2022 +0100

    random: do not take pool spinlock at boot
    
    commit afba0b80b977b2a8f16234f2acd982f82710ba33 upstream.
    
    Since rand_initialize() is run while interrupts are still off and
    nothing else is running, we don't need to repeatedly take and release
    the pool spinlock, especially in the RDSEED loop.
    
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80adfc1fa6910c5e90720b7fb9c7a1686b8ccd58
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 4 16:15:46 2022 +0100

    random: defer fast pool mixing to worker
    
    commit 58340f8e952b613e0ead0bed58b97b05bf4743c5 upstream.
    
    On PREEMPT_RT, it's problematic to take spinlocks from hard irq
    handlers. We can fix this by deferring to a workqueue the dumping of
    the fast pool into the input pool.
    
    We accomplish this with some careful rules on fast_pool->count:
    
      - When it's incremented to >= 64, we schedule the work.
      - If the top bit is set, we never schedule the work, even if >= 64.
      - The worker is responsible for setting it back to 0 when it's done.
    
    There are two small issues around using workqueues for this purpose that
    we work around.
    
    The first issue is that mix_interrupt_randomness() might be migrated to
    another CPU during CPU hotplug. This issue is rectified by checking that
    it hasn't been migrated (after disabling irqs). If it has been migrated,
    then we set the count to zero, so that when the CPU comes online again,
    it can requeue the work. As part of this, we switch to using an
    atomic_t, so that the increment in the irq handler doesn't wipe out the
    zeroing if the CPU comes back online while this worker is running.
    
    The second issue is that, though relatively minor in effect, we probably
    want to make sure we get a consistent view of the pool onto the stack,
    in case it's interrupted by an irq while reading. To do this, we don't
    reenable irqs until after the copy. There are only 18 instructions
    between the cli and sti, so this is a pretty tiny window.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3fa3d153ad2d02922a6c3c9cb62a6c992a79951
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:29:33 2022 +0100

    random: rewrite header introductory comment
    
    commit 5f75d9f3babea8ae0a2d06724656874f41d317f5 upstream.
    
    Now that we've re-documented the various sections, we can remove the
    outdated text here and replace it with a high-level overview.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57332ead20e16aa7403a5892ba7f726a895a8826
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:53:34 2022 +0100

    random: group sysctl functions
    
    commit 0deff3c43206c24e746b1410f11125707ad3040e upstream.
    
    This pulls all of the sysctl-focused functions into the sixth labeled
    section.
    
    No functional changes.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3502a795f6acbf073fb0a22cade3fd94d773aef
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:53:34 2022 +0100

    random: group userspace read/write functions
    
    commit a6adf8e7a605250b911e94793fd077933709ff9e upstream.
    
    This pulls all of the userspace read/write-focused functions into the
    fifth labeled section.
    
    No functional changes.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 496b91b6dc443adf1953126eea66cc931b4a636b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:53:34 2022 +0100

    random: group entropy collection functions
    
    commit 92c653cf14400946f376a29b828d6af7e01f38dd upstream.
    
    This pulls all of the entropy collection-focused functions into the
    fourth labeled section.
    
    No functional changes.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ee36c835e91e38bf27960d56e662ee56f1a3faf
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:53:34 2022 +0100

    random: group entropy extraction functions
    
    commit a5ed7cb1a7732ef11959332d507889fbc39ebbb4 upstream.
    
    This pulls all of the entropy extraction-focused functions into the
    third labeled section.
    
    No functional changes.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25061d366b706f4b1444add67d397a102f8f4350
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:53:34 2022 +0100

    random: group initialization wait functions
    
    commit 5f1bb112006b104b3e2a1e1b39bbb9b2617581e6 upstream.
    
    This pulls all of the readiness waiting-focused functions into the first
    labeled section.
    
    No functional changes.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee5705cffcc844420ffe7eb07ce7250a6dab32c4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 13:41:41 2022 +0100

    random: remove whitespace and reorder includes
    
    commit 87e7d5abad0cbc9312dea7f889a57d294c1a5fcc upstream.
    
    This is purely cosmetic. Future work involves figuring out which of
    these headers we need and which we don't.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 388e4979d6e161e834684b21dc8bef0a77bdd72d
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:28:33 2022 +0100

    random: remove useless header comment
    
    commit 6071a6c0fba2d747742cadcbb3ba26ed756ed73b upstream.
    
    This really adds nothing at all useful.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65419e900306cdcdfb4354445e6a1f54161757a1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:19:49 2022 +0100

    random: introduce drain_entropy() helper to declutter crng_reseed()
    
    commit 246c03dd899164d0186b6d685d6387f228c28d93 upstream.
    
    In preparation for separating responsibilities, break out the entropy
    count management part of crng_reseed() into its own function.
    
    No functional changes.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0a5363f51f501731df3a3b69849f0c2b6fbf34e
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 10 17:01:27 2022 +0100

    random: deobfuscate irq u32/u64 contributions
    
    commit b2f408fe403800c91a49f6589d95b6759ce1b30b upstream.
    
    In the irq handler, we fill out 16 bytes differently on 32-bit and
    64-bit platforms, and for 32-bit vs 64-bit cycle counters, which doesn't
    always correspond with the bitness of the platform. Whether or not you
    like this strangeness, it is a matter of fact.  But it might not be a
    fact you well realized until now, because the code that loaded the irq
    info into 4 32-bit words was quite confusing.  Instead, this commit
    makes everything explicit by having separate (compile-time) branches for
    32-bit and 64-bit types.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fabaab48f24c7b9d3d5ae417d3f5ccccd28c8afa
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 10 16:43:57 2022 +0100

    random: add proper SPDX header
    
    commit a07fdae346c35c6ba286af1c88e0effcfa330bf9 upstream.
    
    Convert the current license into the SPDX notation of "(GPL-2.0 OR
    BSD-3-Clause)". This infers GPL-2.0 from the text "ALTERNATIVELY, this
    product may be distributed under the terms of the GNU General Public
    License, in which case the provisions of the GPL are required INSTEAD OF
    the above restrictions" and it infers BSD-3-Clause from the verbatim
    BSD 3 clause license in the file.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 707c01fe19eb2128374d1a71b7b6d1c9ee2d379f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 10 16:40:44 2022 +0100

    random: remove unused tracepoints
    
    commit 14c174633f349cb41ea90c2c0aaddac157012f74 upstream.
    
    These explicit tracepoints aren't really used and show sign of aging.
    It's work to keep these up to date, and before I attempted to keep them
    up to date, they weren't up to date, which indicates that they're not
    really used. These days there are better ways of introspecting anyway.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8a196cf475177880dc46abf118b7592c92e659a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 10 16:35:24 2022 +0100

    random: remove ifdef'd out interrupt bench
    
    commit 95e6060c20a7f5db60163274c5222a725ac118f9 upstream.
    
    With tools like kbench9000 giving more finegrained responses, and this
    basically never having been used ever since it was initially added,
    let's just get rid of this. There *is* still work to be done on the
    interrupt handler, but this really isn't the way it's being developed.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15c96d9cb50df0a5d72da08e622ab26805a4b3a8
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Feb 9 22:46:48 2022 +0100

    random: tie batched entropy generation to base_crng generation
    
    commit 0791e8b655cc373718f0f58800fdc625a3447ac5 upstream.
    
    Now that we have an explicit base_crng generation counter, we don't need
    a separate one for batched entropy. Rather, we can just move the
    generation forward every time we change crng_init state or update the
    base_crng key.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93ce4028c4e2b689bc1d180c301c8b236e784bab
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Feb 9 18:42:13 2022 +0100

    random: zero buffer after reading entropy from userspace
    
    commit 7b5164fb1279bf0251371848e40bae646b59b3a8 upstream.
    
    This buffer may contain entropic data that shouldn't stick around longer
    than needed, so zero out the temporary buffer at the end of write_pool().
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Jann Horn <jannh@google.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21682884c699e09739c1851d83f4426b653e33e6
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Feb 7 23:37:13 2022 +0100

    random: remove outdated INT_MAX >> 6 check in urandom_read()
    
    commit 434537ae54ad37e93555de21b6ac8133d6d773a9 upstream.
    
    In 79a8468747c5 ("random: check for increase of entropy_count because of
    signed conversion"), a number of checks were added around what values
    were passed to account(), because account() was doing fancy fixed point
    fractional arithmetic, and a user had some ability to pass large values
    directly into it. One of things in that commit was limiting those values
    to INT_MAX >> 6. The first >> 3 was for bytes to bits, and the next >> 3
    was for bits to 1/8 fractional bits.
    
    However, for several years now, urandom reads no longer touch entropy
    accounting, and so this check serves no purpose. The current flow is:
    
    urandom_read_nowarn()-->get_random_bytes_user()-->chacha20_block()
    
    Of course, we don't want that size_t to be truncated when adding it into
    the ssize_t. But we arrive at urandom_read_nowarn() in the first place
    either via ordinary fops, which limits reads to MAX_RW_COUNT, or via
    getrandom() which limits reads to INT_MAX.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Jann Horn <jannh@google.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acbf6f4851e3d3815fa8907afffbbcf9140eb3f4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 8 19:23:17 2022 +0100

    random: use hash function for crng_slow_load()
    
    commit 66e4c2b9541503d721e936cc3898c9f25f4591ff upstream.
    
    Since we have a hash function that's really fast, and the goal of
    crng_slow_load() is reportedly to "touch all of the crng's state", we
    can just hash the old state together with the new state and call it a
    day. This way we dont need to reason about another LFSR or worry about
    various attacks there. This code is only ever used at early boot and
    then never again.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a595c18329ee6fe9c35c2dfa18346b20ff89d7a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Feb 9 01:56:35 2022 +0100

    random: absorb fast pool into input pool after fast load
    
    commit c30c575db4858f0bbe5e315ff2e529c782f33a1f upstream.
    
    During crng_init == 0, we never credit entropy in add_interrupt_
    randomness(), but instead dump it directly into the primary_crng. That's
    fine, except for the fact that we then wind up throwing away that
    entropy later when we switch to extracting from the input pool and
    xoring into (and later in this series overwriting) the primary_crng key.
    The two other early init sites -- add_hwgenerator_randomness()'s use
    crng_fast_load() and add_device_ randomness()'s use of crng_slow_load()
    -- always additionally give their inputs to the input pool. But not
    add_interrupt_randomness().
    
    This commit fixes that shortcoming by calling mix_pool_bytes() after
    crng_fast_load() in add_interrupt_randomness(). That's partially
    verboten on PREEMPT_RT, where it implies taking spinlock_t from an IRQ
    handler. But this also only happens during early boot and then never
    again after that. Plus it's a trylock so it has the same considerations
    as calling crng_fast_load(), which we're already using.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Suggested-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d9c1b42a51c0ed22eb993dfad2f7b368f6f6d14
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 8 13:00:11 2022 +0100

    random: do not xor RDRAND when writing into /dev/random
    
    commit 91c2afca290ed3034841c8c8532e69ed9e16cf34 upstream.
    
    Continuing the reasoning of "random: ensure early RDSEED goes through
    mixer on init", we don't want RDRAND interacting with anything without
    going through the mixer function, as a backdoored CPU could presumably
    cancel out data during an xor, which it'd have a harder time doing when
    being forced through a cryptographic hash function. There's actually no
    need at all to be calling RDRAND in write_pool(), because before we
    extract from the pool, we always do so with 32 bytes of RDSEED hashed in
    at that stage. Xoring at this stage is needless and introduces a minor
    liability.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ceb0d570cf9c409738ea7343182b7c479c6290a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 8 12:44:28 2022 +0100

    random: ensure early RDSEED goes through mixer on init
    
    commit a02cf3d0dd77244fd5333ac48d78871de459ae6d upstream.
    
    Continuing the reasoning of "random: use RDSEED instead of RDRAND in
    entropy extraction" from this series, at init time we also don't want to
    be xoring RDSEED directly into the crng. Instead it's safer to put it
    into our entropy collector and then re-extract it, so that it goes
    through a hash function with preimage resistance. As a matter of hygiene,
    we also order these now so that the RDSEED byte are hashed in first,
    followed by the bytes that are likely more predictable (e.g. utsname()).
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13c423b6b1d3ab2e84f4ac0afe9e3b217d2a26e8
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 8 12:40:14 2022 +0100

    random: inline leaves of rand_initialize()
    
    commit 8566417221fcec51346ec164e920dacb979c6b5f upstream.
    
    This is a preparatory commit for the following one. We simply inline the
    various functions that rand_initialize() calls that have no other
    callers. The compiler was doing this anyway before. Doing this will
    allow us to reorganize this after. We can then move the trust_cpu and
    parse_trust_cpu definitions a bit closer to where they're actually used,
    which makes the code easier to read.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0841f7e4ae675d75dafd11a154913155990eb9f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Feb 8 12:18:33 2022 +0100

    random: use RDSEED instead of RDRAND in entropy extraction
    
    commit 28f425e573e906a4c15f8392cc2b1561ef448595 upstream.
    
    When /dev/random was directly connected with entropy extraction, without
    any expansion stage, extract_buf() was called for every 10 bytes of data
    read from /dev/random. For that reason, RDRAND was used rather than
    RDSEED. At the same time, crng_reseed() was still only called every 5
    minutes, so there RDSEED made sense.
    
    Those olden days were also a time when the entropy collector did not use
    a cryptographic hash function, which meant most bets were off in terms
    of real preimage resistance. For that reason too it didn't matter
    _that_ much whether RDSEED was mixed in before or after entropy
    extraction; both choices were sort of bad.
    
    But now we have a cryptographic hash function at work, and with that we
    get real preimage resistance. We also now only call extract_entropy()
    every 5 minutes, rather than every 10 bytes. This allows us to do two
    important things.
    
    First, we can switch to using RDSEED in extract_entropy(), as Dominik
    suggested. Second, we can ensure that RDSEED input always goes into the
    cryptographic hash function with other things before being used
    directly. This eliminates a category of attacks in which the CPU knows
    the current state of the crng and knows that we're going to xor RDSEED
    into it, and so it computes a malicious RDSEED. By going through our
    hash function, it would require the CPU to compute a preimage on the
    fly, which isn't going to happen.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 909f3974c58c20a7501d4c185d3b22d56951f007
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Sat Feb 5 11:34:57 2022 +0100

    random: fix locking in crng_fast_load()
    
    commit 7c2fe2b32bf76441ff5b7a425b384e5f75aa530a upstream.
    
    crng_init is protected by primary_crng->lock, so keep holding that lock
    when incrementing crng_init from 0 to 1 in crng_fast_load(). The call to
    pr_notice() can wait until the lock is released; this code path cannot
    be reached twice, as crng_fast_load() aborts early if crng_init > 0.
    
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 839a45e6864da6d8a601ac2507268f555b8efb81
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Jan 28 23:29:45 2022 +0100

    random: remove batched entropy locking
    
    commit 77760fd7f7ae3dfd03668204e708d1568d75447d upstream.
    
    Rather than use spinlocks to protect batched entropy, we can instead
    disable interrupts locally, since we're dealing with per-cpu data, and
    manage resets with a basic generation counter. At the same time, we
    can't quite do this on PREEMPT_RT, where we still want spinlocks-as-
    mutexes semantics. So we use a local_lock_t, which provides the right
    behavior for each. Because this is a per-cpu lock, that generation
    counter is still doing the necessary CPU-to-CPU communication.
    
    This should improve performance a bit. It will also fix the linked splat
    that Jonathan received with a PROVE_RAW_LOCK_NESTING=y.
    
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Suggested-by: Andy Lutomirski <luto@kernel.org>
    Reported-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
    Tested-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
    Link: https://lore.kernel.org/lkml/YfMa0QgsjCVdRAvJ@latitude/
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c39bfd9db3c67e689dea3c6bd6345c9888ad1c4
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Feb 4 14:17:33 2022 -0800

    random: remove use_input_pool parameter from crng_reseed()
    
    commit 5d58ea3a31cc98b9fa563f6921d3d043bf0103d1 upstream.
    
    The primary_crng is always reseeded from the input_pool, while the NUMA
    crngs are always reseeded from the primary_crng.  Remove the redundant
    'use_input_pool' parameter from crng_reseed() and just directly check
    whether the crng is the primary_crng.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6605171cd8cb927fddc75cd6f4cfab50e91c5b5b
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 4 01:45:53 2022 +0100

    random: make credit_entropy_bits() always safe
    
    commit a49c010e61e1938be851f5e49ac219d49b704103 upstream.
    
    This is called from various hwgenerator drivers, so rather than having
    one "safe" version for userspace and one "unsafe" version for the
    kernel, just make everything safe; the checks are cheap and sensible to
    have anyway.
    
    Reported-by: Sultan Alsawaf <sultan@kerneltoast.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f82262f273f1b11d2b5a54619143ac3c1f1b7763
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Feb 5 14:00:58 2022 +0100

    random: always wake up entropy writers after extraction
    
    commit 489c7fc44b5740d377e8cfdbf0851036e493af00 upstream.
    
    Now that POOL_BITS == POOL_MIN_BITS, we must unconditionally wake up
    entropy writers after every extraction. Therefore there's no point of
    write_wakeup_threshold, so we can move it to the dustbin of unused
    compatibility sysctls. While we're at it, we can fix a small comparison
    where we were waking up after <= min rather than < min.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Suggested-by: Eric Biggers <ebiggers@kernel.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb375abdbf1166013071ae91e36f335601192ca4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 3 13:28:06 2022 +0100

    random: use linear min-entropy accumulation crediting
    
    commit c570449094844527577c5c914140222cb1893e3f upstream.
    
    30e37ec516ae ("random: account for entropy loss due to overwrites")
    assumed that adding new entropy to the LFSR pool probabilistically
    cancelled out old entropy there, so entropy was credited asymptotically,
    approximating Shannon entropy of independent sources (rather than a
    stronger min-entropy notion) using 1/8th fractional bits and replacing
    a constant 2-2/√𝑒 term (~0.786938) with 3/4 (0.75) to slightly
    underestimate it. This wasn't superb, but it was perhaps better than
    nothing, so that's what was done. Which entropy specifically was being
    cancelled out and how much precisely each time is hard to tell, though
    as I showed with the attack code in my previous commit, a motivated
    adversary with sufficient information can actually cancel out
    everything.
    
    Since we're no longer using an LFSR for entropy accumulation, this
    probabilistic cancellation is no longer relevant. Rather, we're now
    using a computational hash function as the accumulator and we've
    switched to working in the random oracle model, from which we can now
    revisit the question of min-entropy accumulation, which is done in
    detail in <https://eprint.iacr.org/2019/198>.
    
    Consider a long input bit string that is built by concatenating various
    smaller independent input bit strings. Each one of these inputs has a
    designated min-entropy, which is what we're passing to
    credit_entropy_bits(h). When we pass the concatenation of these to a
    random oracle, it means that an adversary trying to receive back the
    same reply as us would need to become certain about each part of the
    concatenated bit string we passed in, which means becoming certain about
    all of those h values. That means we can estimate the accumulation by
    simply adding up the h values in calls to credit_entropy_bits(h);
    there's no probabilistic cancellation at play like there was said to be
    for the LFSR. Incidentally, this is also what other entropy accumulators
    based on computational hash functions do as well.
    
    So this commit replaces credit_entropy_bits(h) with essentially `total =
    min(POOL_BITS, total + h)`, done with a cmpxchg loop as before.
    
    What if we're wrong and the above is nonsense? It's not, but let's
    assume we don't want the actual _behavior_ of the code to change much.
    Currently that behavior is not extracting from the input pool until it
    has 128 bits of entropy in it. With the old algorithm, we'd hit that
    magic 128 number after roughly 256 calls to credit_entropy_bits(1). So,
    we can retain more or less the old behavior by waiting to extract from
    the input pool until it hits 256 bits of entropy using the new code. For
    people concerned about this change, it means that there's not that much
    practical behavioral change. And for folks actually trying to model
    the behavior rigorously, it means that we have an even higher margin
    against attacks.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62a2b4bd3ec9e30514466863e06b30f3305b4bb5
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Feb 2 13:30:03 2022 +0100

    random: simplify entropy debiting
    
    commit 9c07f57869e90140080cfc282cc628d123e27704 upstream.
    
    Our pool is 256 bits, and we only ever use all of it or don't use it at
    all, which is decided by whether or not it has at least 128 bits in it.
    So we can drastically simplify the accounting and cmpxchg loop to do
    exactly this.  While we're at it, we move the minimum bit size into a
    constant so it can be shared between the two places where it matters.
    
    The reason we want any of this is for the case in which an attacker has
    compromised the current state, and then bruteforces small amounts of
    entropy added to it. By demanding a particular minimum amount of entropy
    be present before reseeding, we make that bruteforcing difficult.
    
    Note that this rationale no longer includes anything about /dev/random
    blocking at the right moment, since /dev/random no longer blocks (except
    for at ~boot), but rather uses the crng. In a former life, /dev/random
    was different and therefore required a more nuanced account(), but this
    is no longer.
    
    Behaviorally, nothing changes here. This is just a simplification of
    the code.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccf535b5077a2e641940ce179de004786972dbd7
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Jan 16 14:23:10 2022 +0100

    random: use computational hash for entropy extraction
    
    commit 6e8ec2552c7d13991148e551e3325a624d73fac6 upstream.
    
    The current 4096-bit LFSR used for entropy collection had a few
    desirable attributes for the context in which it was created. For
    example, the state was huge, which meant that /dev/random would be able
    to output quite a bit of accumulated entropy before blocking. It was
    also, in its time, quite fast at accumulating entropy byte-by-byte,
    which matters given the varying contexts in which mix_pool_bytes() is
    called. And its diffusion was relatively high, which meant that changes
    would ripple across several words of state rather quickly.
    
    However, it also suffers from a few security vulnerabilities. In
    particular, inputs learned by an attacker can be undone, but moreover,
    if the state of the pool leaks, its contents can be controlled and
    entirely zeroed out. I've demonstrated this attack with this SMT2
    script, <https://xn--4db.cc/5o9xO8pb>, which Boolector/CaDiCal solves in
    a matter of seconds on a single core of my laptop, resulting in little
    proof of concept C demonstrators such as <https://xn--4db.cc/jCkvvIaH/c>.
    
    For basically all recent formal models of RNGs, these attacks represent
    a significant cryptographic flaw. But how does this manifest
    practically? If an attacker has access to the system to such a degree
    that he can learn the internal state of the RNG, arguably there are
    other lower hanging vulnerabilities -- side-channel, infoleak, or
    otherwise -- that might have higher priority. On the other hand, seed
    files are frequently used on systems that have a hard time generating
    much entropy on their own, and these seed files, being files, often leak
    or are duplicated and distributed accidentally, or are even seeded over
    the Internet intentionally, where their contents might be recorded or
    tampered with. Seen this way, an otherwise quasi-implausible
    vulnerability is a bit more practical than initially thought.
    
    Another aspect of the current mix_pool_bytes() function is that, while
    its performance was arguably competitive for the time in which it was
    created, it's no longer considered so. This patch improves performance
    significantly: on a high-end CPU, an i7-11850H, it improves performance
    of mix_pool_bytes() by 225%, and on a low-end CPU, a Cortex-A7, it
    improves performance by 103%.
    
    This commit replaces the LFSR of mix_pool_bytes() with a straight-
    forward cryptographic hash function, BLAKE2s, which is already in use
    for pool extraction. Universal hashing with a secret seed was considered
    too, something along the lines of <https://eprint.iacr.org/2013/338>,
    but the requirement for a secret seed makes for a chicken & egg problem.
    Instead we go with a formally proven scheme using a computational hash
    function, described in sections 5.1, 6.4, and B.1.8 of
    <https://eprint.iacr.org/2019/198>.
    
    BLAKE2s outputs 256 bits, which should give us an appropriate amount of
    min-entropy accumulation, and a wide enough margin of collision
    resistance against active attacks. mix_pool_bytes() becomes a simple
    call to blake2s_update(), for accumulation, while the extraction step
    becomes a blake2s_final() to generate a seed, with which we can then do
    a HKDF-like or BLAKE2X-like expansion, the first part of which we fold
    back as an init key for subsequent blake2s_update()s, and the rest we
    produce to the caller. This then is provided to our CRNG like usual. In
    that expansion step, we make opportunistic use of 32 bytes of RDRAND
    output, just as before. We also always reseed the crng with 32 bytes,
    unconditionally, or not at all, rather than sometimes with 16 as before,
    as we don't win anything by limiting beyond the 16 byte threshold.
    
    Going for a hash function as an entropy collector is a conservative,
    proven approach. The result of all this is a much simpler and much less
    bespoke construction than what's there now, which not only plugs a
    vulnerability but also improves performance considerably.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ad714b9dced98e0a9b88f7e1884e5baad019570
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Sun Jan 30 22:03:20 2022 +0100

    random: only call crng_finalize_init() for primary_crng
    
    commit 9d5505f1eebeca778074a0260ed077fd85f8792c upstream.
    
    crng_finalize_init() returns instantly if it is called for another pool
    than primary_crng. The test whether crng_finalize_init() is still required
    can be moved to the relevant caller in crng_reseed(), and
    crng_need_final_init can be reset to false if crng_finalize_init() is
    called with workqueues ready. Then, no previous callsite will call
    crng_finalize_init() unless it is needed, and we can get rid of the
    superfluous function parameter.
    
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7beef135045b31760599675f1f7e6caaa6db31bc
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Sun Jan 30 22:03:19 2022 +0100

    random: access primary_pool directly rather than through pointer
    
    commit ebf7606388732ecf2821ca21087e9446cb4a5b57 upstream.
    
    Both crng_initialize_primary() and crng_init_try_arch_early() are
    only called for the primary_pool. Accessing it directly instead of
    through a function parameter simplifies the code.
    
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35e312919dd97bd28b26c035ac892ee4cdba0dde
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Tue Jan 25 21:14:57 2022 +0100

    random: continually use hwgenerator randomness
    
    commit c321e907aa4803d562d6e70ebed9444ad082f953 upstream.
    
    The rngd kernel thread may sleep indefinitely if the entropy count is
    kept above random_write_wakeup_bits by other entropy sources. To make
    best use of multiple sources of randomness, mix entropy from hardware
    RNGs into the pool at least once within CRNG_RESEED_INTERVAL.
    
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c539eee39b2d922a339690edec2f715fb4f1cc1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jan 17 18:43:02 2022 +0100

    random: simplify arithmetic function flow in account()
    
    commit a254a0e4093fce8c832414a83940736067eed515 upstream.
    
    Now that have_bytes is never modified, we can simplify this function.
    First, we move the check for negative entropy_count to be first. That
    ensures that subsequent reads of this will be non-negative. Then,
    have_bytes and ibytes can be folded into their one use site in the
    min_t() function.
    
    Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 166f9970b82af96899566d30a1ef199e09c46b71
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Jan 15 14:40:04 2022 +0100

    random: access input_pool_data directly rather than through pointer
    
    commit 6c0eace6e1499712583b6ee62d95161e8b3449f5 upstream.
    
    This gets rid of another abstraction we no longer need. It would be nice
    if we could instead make pool an array rather than a pointer, but the
    latent entropy plugin won't be able to do its magic in that case. So
    instead we put all accesses to the input pool's actual data through the
    input_pool_data array directly.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 563845199476a6ded17bde9a3163101c99ede919
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jan 13 18:18:48 2022 +0100

    random: cleanup fractional entropy shift constants
    
    commit 18263c4e8e62f7329f38f5eadc568751242ca89c upstream.
    
    The entropy estimator is calculated in terms of 1/8 bits, which means
    there are various constants where things are shifted by 3. Move these
    into our pool info enum with the other relevant constants. While we're
    at it, move an English assertion about sizes into a proper BUILD_BUG_ON
    so that the compiler can ensure this invariant.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a88fa6c02cb18d6c58eca53f94e222672f234428
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Jan 14 16:48:35 2022 +0100

    random: prepend remaining pool constants with POOL_
    
    commit b3d51c1f542113342ddfbf6007e38a684b9dbec9 upstream.
    
    The other pool constants are prepended with POOL_, but not these last
    ones. Rename them. This will then let us move them into the enum in the
    following commit.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9199cebaf68beca744e3e98534a58e297066fd27
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jan 13 16:11:21 2022 +0100

    random: de-duplicate INPUT_POOL constants
    
    commit 5b87adf30f1464477169a1d653e9baf8c012bbfe upstream.
    
    We already had the POOL_* constants, so deduplicate the older INPUT_POOL
    ones. As well, fold EXTRACT_SIZE into the poolinfo enum, since it's
    related.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3653dd775a92464868bd22632899b9a8db1ea155
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jan 13 15:51:06 2022 +0100

    random: remove unused OUTPUT_POOL constants
    
    commit 0f63702718c91d89c922081ac1e6baeddc2d8b1a upstream.
    
    We no longer have an output pool. Rather, we have just a wakeup bits
    threshold for /dev/random reads, presumably so that processes don't
    hang. This value, random_write_wakeup_bits, is configurable anyway. So
    all the no longer usefully named OUTPUT_POOL constants were doing was
    setting a reasonable default for random_write_wakeup_bits. This commit
    gets rid of the constants and just puts it all in the default value of
    random_write_wakeup_bits.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55349296ba9b060d41129a074fc5d8414d83682f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Jan 12 17:18:08 2022 +0100

    random: rather than entropy_store abstraction, use global
    
    commit 90ed1e67e896cc8040a523f8428fc02f9b164394 upstream.
    
    Originally, the RNG used several pools, so having things abstracted out
    over a generic entropy_store object made sense. These days, there's only
    one input pool, and then an uneven mix of usage via the abstraction and
    usage via &input_pool. Rather than this uneasy mixture, just get rid of
    the abstraction entirely and have things always use the global. This
    simplifies the code and makes reading it a bit easier.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 482583b75f5f04eeac0e91ad2676d7d1d4abb97d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 28 16:53:52 2019 -0700

    random: try to actively add entropy rather than passively wait for it
    
    commit 50ee7529ec4500c88f8664560770a7a1b65db72b upstream.
    
    For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
    caused a bootup regression due to lack of entropy at bootup together
    with arguably broken user space that was asking for secure random
    numbers when it really didn't need to.
    
    See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug").
    
    This aims to solve the issue by actively generating entropy noise using
    the CPU cycle counter when waiting for the random number generator to
    initialize.  This only works when you have a high-frequency time stamp
    counter available, but that's the case on all modern x86 CPU's, and on
    most other modern CPU's too.
    
    What we do is to generate jitter entropy from the CPU cycle counter
    under a somewhat complex load: calling the scheduler while also
    guaranteeing a certain amount of timing noise by also triggering a
    timer.
    
    I'm sure we can tweak this, and that people will want to look at other
    alternatives, but there's been a number of papers written on jitter
    entropy, and this should really be fairly conservative by crediting one
    bit of entropy for every timer-induced jump in the cycle counter.  Not
    because the timer itself would be all that unpredictable, but because
    the interaction between the timer and the loop is going to be.
    
    Even if (and perhaps particularly if) the timer actually happens on
    another CPU, the cacheline interaction between the loop that reads the
    cycle counter and the timer itself firing is going to add perturbations
    to the cycle counter values that get mixed into the entropy pool.
    
    As Thomas pointed out, with a modern out-of-order CPU, even quite simple
    loops show a fair amount of hard-to-predict timing variability even in
    the absense of external interrupts.  But this tries to take that further
    by actually having a fairly complex interaction.
    
    This is not going to solve the entropy issue for architectures that have
    no CPU cycle counter, but it's not clear how (and if) that is solvable,
    and the hardware in question is largely starting to be irrelevant.  And
    by doing this we can at least avoid some of the even more contentious
    approaches (like making the entropy waiting time out in order to avoid
    the possibly unbounded waiting).
    
    Cc: Ahmed Darwish <darwish.07@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Nicholas Mc Guire <hofrat@opentech.at>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: Alexander E. Patrakov <patrakov@gmail.com>
    Cc: Lennart Poettering <mzxreary@0pointer.de>
    Cc: Noah Meyerhans <noahm@debian.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac800f0b08577e78216da44a4185030a0466dd4a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Jan 12 15:28:21 2022 +0100

    random: remove unused extract_entropy() reserved argument
    
    commit 8b2d953b91e7f60200c24067ab17b77cc7bfd0d4 upstream.
    
    This argument is always set to zero, as a result of us not caring about
    keeping a certain amount reserved in the pool these days. So just remove
    it and cleanup the function signatures.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c8cc8dbe8eaab05535202eb457c34df1c38fe97
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Jan 12 15:22:30 2022 +0100

    random: remove incomplete last_data logic
    
    commit a4bfa9b31802c14ff5847123c12b98d5e36b3985 upstream.
    
    There were a few things added under the "if (fips_enabled)" banner,
    which never really got completed, and the FIPS people anyway are
    choosing a different direction. Rather than keep around this halfbaked
    code, get rid of it so that we can focus on a single design of the RNG
    rather than two designs.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f450937d22e639173cd5c730c0b3a0a710b243d0
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Jan 9 17:48:58 2022 +0100

    random: cleanup integer types
    
    commit d38bb0853589c939573ea50e9cb64f733e0e273d upstream.
    
    Rather than using the userspace type, __uXX, switch to using uXX. And
    rather than using variously chosen `char *` or `unsigned char *`, use
    `u8 *` uniformly for things that aren't strings, in the case where we
    are doing byte-by-byte traversal.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91393740d75fde2fa9bd329ea1f2723f90c5f26d
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Sep 11 20:05:10 2018 -0700

    crypto: chacha20 - Fix chacha20_block() keystream alignment (again)
    
    [ Upstream commit a5e9f557098e54af44ade5d501379be18435bfbf ]
    
    In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
    chacha20_block()"), I had missed that chacha20_block() can be called
    directly on the buffer passed to get_random_bytes(), which can have any
    alignment.  So, while my commit didn't break anything, it didn't fully
    solve the alignment problems.
    
    Revert my solution and just update chacha20_block() to use
    put_unaligned_le32(), so the output buffer need not be aligned.
    This is simpler, and on many CPUs it's the same speed.
    
    But, I kept the 'tmp' buffers in extract_crng_user() and
    _get_random_bytes() 4-byte aligned, since that alignment is actually
    needed for _crng_backtrack_protect() too.
    
    Reported-by: Stephan Müller <smueller@chronox.de>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45b1bfbd54bc1849cd95655317d86b73764ebfe9
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Jan 9 17:32:02 2022 +0100

    random: cleanup poolinfo abstraction
    
    commit 91ec0fe138f107232cb36bc6112211db37cb5306 upstream.
    
    Now that we're only using one polynomial, we can cleanup its
    representation into constants, instead of passing around pointers
    dynamically to select different polynomials. This improves the codegen
    and makes the code a bit more straightforward.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da31a02410effc095f1a9ed826f4cf67a2179782
Author: Schspa Shi <schspa@gmail.com>
Date:   Fri Jan 14 16:12:16 2022 +0800

    random: fix typo in comments
    
    commit c0a8a61e7abbf66729687ee63659ee25983fbb1e upstream.
    
    s/or/for
    
    Signed-off-by: Schspa Shi <schspa@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28601bec7c3f572bf2e574af9bdcc26873817d4d
Author: Jann Horn <jannh@google.com>
Date:   Mon Jan 3 16:59:31 2022 +0100

    random: don't reset crng_init_cnt on urandom_read()
    
    commit 6c8e11e08a5b74bb8a5cdd5cbc1e5143df0fba72 upstream.
    
    At the moment, urandom_read() (used for /dev/urandom) resets crng_init_cnt
    to zero when it is called at crng_init<2. This is inconsistent: We do it
    for /dev/urandom reads, but not for the equivalent
    getrandom(GRND_INSECURE).
    
    (And worse, as Jason pointed out, we're only doing this as long as
    maxwarn>0.)
    
    crng_init_cnt is only read in crng_fast_load(); it is relevant at
    crng_init==0 for determining when to switch to crng_init==1 (and where in
    the RNG state array to write).
    
    As far as I understand:
    
     - crng_init==0 means "we have nothing, we might just be returning the same
       exact numbers on every boot on every machine, we don't even have
       non-cryptographic randomness; we should shove every bit of entropy we
       can get into the RNG immediately"
     - crng_init==1 means "well we have something, it might not be
       cryptographic, but at least we're not gonna return the same data every
       time or whatever, it's probably good enough for TCP and ASLR and stuff;
       we now have time to build up actual cryptographic entropy in the input
       pool"
     - crng_init==2 means "this is supposed to be cryptographically secure now,
       but we'll keep adding more entropy just to be sure".
    
    The current code means that if someone is pulling data from /dev/urandom
    fast enough at crng_init==0, we'll keep resetting crng_init_cnt, and we'll
    never make forward progress to crng_init==1. It seems to be intended to
    prevent an attacker from bruteforcing the contents of small individual RNG
    inputs on the way from crng_init==0 to crng_init==1, but that's misguided;
    crng_init==1 isn't supposed to provide proper cryptographic security
    anyway, RNG users who care about getting secure RNG output have to wait
    until crng_init==2.
    
    This code was inconsistent, and it probably made things worse - just get
    rid of it.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d15b7abb41918efbeadf27119d67bdfbcff422e3
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Dec 30 17:50:52 2021 +0100

    random: avoid superfluous call to RDRAND in CRNG extraction
    
    commit 2ee25b6968b1b3c66ffa408de23d023c1bce81cf upstream.
    
    RDRAND is not fast. RDRAND is actually quite slow. We've known this for
    a while, which is why functions like get_random_u{32,64} were converted
    to use batching of our ChaCha-based CRNG instead.
    
    Yet CRNG extraction still includes a call to RDRAND, in the hot path of
    every call to get_random_bytes(), /dev/urandom, and getrandom(2).
    
    This call to RDRAND here seems quite superfluous. CRNG is already
    extracting things based on a 256-bit key, based on good entropy, which
    is then reseeded periodically, updated, backtrack-mutated, and so
    forth. The CRNG extraction construction is something that we're already
    relying on to be secure and solid. If it's not, that's a serious
    problem, and it's unlikely that mixing in a measly 32 bits from RDRAND
    is going to alleviate things.
    
    And in the case where the CRNG doesn't have enough entropy yet, we're
    already initializing the ChaCha key row with RDRAND in
    crng_init_try_arch_early().
    
    Removing the call to RDRAND improves performance on an i7-11850H by
    370%. In other words, the vast majority of the work done by
    extract_crng() prior to this commit was devoted to fetching 32 bits of
    RDRAND.
    
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d4b3fc01e0fe47688ab082cdc1780673fb81ec0
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Fri Dec 31 09:26:08 2021 +0100

    random: early initialization of ChaCha constants
    
    commit 96562f286884e2db89c74215b199a1084b5fb7f7 upstream.
    
    Previously, the ChaCha constants for the primary pool were only
    initialized in crng_initialize_primary(), called by rand_initialize().
    However, some randomness is actually extracted from the primary pool
    beforehand, e.g. by kmem_cache_create(). Therefore, statically
    initialize the ChaCha constants for the primary pool.
    
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: <linux-crypto@vger.kernel.org>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84647efd92bfb03569b12751d00ed0cde0b49b2d
Author: Eric Biggers <ebiggers@google.com>
Date:   Sun Mar 21 22:13:47 2021 -0700

    random: initialize ChaCha20 constants with correct endianness
    
    commit a181e0fdb2164268274453b5b291589edbb9b22d upstream.
    
    On big endian CPUs, the ChaCha20-based CRNG is using the wrong
    endianness for the ChaCha20 constants.
    
    This doesn't matter cryptographically, but technically it means it's not
    ChaCha20 anymore.  Fix it to always use the standard constants.
    
    Cc: linux-crypto@vger.kernel.org
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Jann Horn <jannh@google.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 048cc34c4cdf82ff5aeebf474de4f23f5def8313
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Dec 30 15:59:26 2021 +0100

    random: use IS_ENABLED(CONFIG_NUMA) instead of ifdefs
    
    commit 7b87324112df2e1f9b395217361626362dcfb9fb upstream.
    
    Rather than an awkward combination of ifdefs and __maybe_unused, we can
    ensure more source gets parsed, regardless of the configuration, by
    using IS_ENABLED for the CONFIG_NUMA conditional code. This makes things
    cleaner and easier to follow.
    
    I've confirmed that on !CONFIG_NUMA, we don't wind up with excess code
    by accident; the generated object file is the same.
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d3c00a79b3e762e355037c3b286310d345dc346
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Wed Dec 29 22:10:07 2021 +0100

    random: harmonize "crng init done" messages
    
    commit 161212c7fd1d9069b232785c75492e50941e2ea8 upstream.
    
    We print out "crng init done" for !TRUST_CPU, so we should also print
    out the same for TRUST_CPU.
    
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66794cda8a8f71039251b78822565fc8ac8a6de1
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Dec 29 22:10:06 2021 +0100

    random: mix bootloader randomness into pool
    
    commit 57826feeedb63b091f807ba8325d736775d39afd upstream.
    
    If we're trusting bootloader randomness, crng_fast_load() is called by
    add_hwgenerator_randomness(), which sets us to crng_init==1. However,
    usually it is only called once for an initial 64-byte push, so bootloader
    entropy will not mix any bytes into the input pool. So it's conceivable
    that crng_init==1 when crng_initialize_primary() is called later, but
    then the input pool is empty. When that happens, the crng state key will
    be overwritten with extracted output from the empty input pool. That's
    bad.
    
    In contrast, if we're not trusting bootloader randomness, we call
    crng_slow_load() *and* we call mix_pool_bytes(), so that later
    crng_initialize_primary() isn't drawing on nothing.
    
    In order to prevent crng_initialize_primary() from extracting an empty
    pool, have the trusted bootloader case mirror that of the untrusted
    bootloader case, mixing the input into the pool.
    
    [linux@dominikbrodowski.net: rewrite commit message]
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e59fd7eb5ca0883059222dbb4ad771904d59b7c0
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Dec 29 22:10:04 2021 +0100

    random: do not re-init if crng_reseed completes before primary init
    
    commit 9c3ddde3f811aabbb83778a2a615bf141b4909ef upstream.
    
    If the bootloader supplies sufficient material and crng_reseed() is called
    very early on, but not too early that wqs aren't available yet, then we
    might transition to crng_init==2 before rand_initialize()'s call to
    crng_initialize_primary() made. Then, when crng_initialize_primary() is
    called, if we're trusting the CPU's RDRAND instructions, we'll
    needlessly reinitialize the RNG and emit a message about it. This is
    mostly harmless, as numa_crng_init() will allocate and then free what it
    just allocated, and excessive calls to invalidate_batched_entropy()
    aren't so harmful. But it is funky and the extra message is confusing,
    so avoid the re-initialization all together by checking for crng_init <
    2 in crng_initialize_primary(), just as we already do in crng_reseed().
    
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaa94d939f2f5799b1ef1fe565164f55c10a483a
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Dec 24 19:17:58 2021 +0100

    random: do not sign extend bytes for rotation when mixing
    
    commit 0d9488ffbf2faddebc6bac055bfa6c93b94056a3 upstream.
    
    By using `char` instead of `unsigned char`, certain platforms will sign
    extend the byte when `w = rol32(*bytes++, input_rotate)` is called,
    meaning that bit 7 is overrepresented when mixing. This isn't a real
    problem (unless the mixer itself is already broken) since it's still
    invertible, but it's not quite correct either. Fix this by using an
    explicit unsigned type.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f89b3175be82fecf9621fe102320660c98e40e3
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Dec 21 16:31:27 2021 +0100

    random: use BLAKE2s instead of SHA1 in extraction
    
    commit 9f9eff85a008b095eafc5f4ecbaf5aca689271c1 upstream.
    
    This commit addresses one of the lower hanging fruits of the RNG: its
    usage of SHA1.
    
    BLAKE2s is generally faster, and certainly more secure, than SHA1, which
    has [1] been [2] really [3] very [4] broken [5]. Additionally, the
    current construction in the RNG doesn't use the full SHA1 function, as
    specified, and allows overwriting the IV with RDRAND output in an
    undocumented way, even in the case when RDRAND isn't set to "trusted",
    which means potential malicious IV choices. And its short length means
    that keeping only half of it secret when feeding back into the mixer
    gives us only 2^80 bits of forward secrecy. In other words, not only is
    the choice of hash function dated, but the use of it isn't really great
    either.
    
    This commit aims to fix both of these issues while also keeping the
    general structure and semantics as close to the original as possible.
    Specifically:
    
       a) Rather than overwriting the hash IV with RDRAND, we put it into
          BLAKE2's documented "salt" and "personal" fields, which were
          specifically created for this type of usage.
       b) Since this function feeds the full hash result back into the
          entropy collector, we only return from it half the length of the
          hash, just as it was done before. This increases the
          construction's forward secrecy from 2^80 to a much more
          comfortable 2^128.
       c) Rather than using the raw "sha1_transform" function alone, we
          instead use the full proper BLAKE2s function, with finalization.
    
    This also has the advantage of supplying 16 bytes at a time rather than
    SHA1's 10 bytes, which, in addition to having a faster compression
    function to begin with, means faster extraction in general. On an Intel
    i7-11850H, this commit makes initial seeding around 131% faster.
    
    BLAKE2s itself has the nice property of internally being based on the
    ChaCha permutation, which the RNG is already using for expansion, so
    there shouldn't be any issue with newness, funkiness, or surprising CPU
    behavior, since it's based on something already in use.
    
    [1] https://eprint.iacr.org/2005/010.pdf
    [2] https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf
    [3] https://eprint.iacr.org/2015/967.pdf
    [4] https://shattered.io/static/shattered.pdf
    [5] https://www.usenix.org/system/files/sec20-leurent.pdf
    
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a0fda8f1b6a6969a1147cda91ce183b5727b5ae
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Dec 7 13:17:33 2021 +0100

    random: remove unused irq_flags argument from add_interrupt_randomness()
    
    commit 703f7066f40599c290babdb79dd61319264987e9 upstream.
    
    Since commit
       ee3e00e9e7101 ("random: use registers from interrupted code for CPU's w/o a cycle counter")
    
    the irq_flags argument is no longer used.
    
    Remove unused irq_flags.
    
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Dexuan Cui <decui@microsoft.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: K. Y. Srinivasan <kys@microsoft.com>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Wei Liu <wei.liu@kernel.org>
    Cc: linux-hyperv@vger.kernel.org
    Cc: x86@kernel.org
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Acked-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cdbdd83c79329c3399aee2776d488988cf9f05f
Author: Mark Brown <broonie@kernel.org>
Date:   Wed Dec 1 17:44:49 2021 +0000

    random: document add_hwgenerator_randomness() with other input functions
    
    commit 2b6c6e3d9ce3aa0e547ac25d60e06fe035cd9f79 upstream.
    
    The section at the top of random.c which documents the input functions
    available does not document add_hwgenerator_randomness() which might lead
    a reader to overlook it. Add a brief note about it.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [Jason: reorganize position of function in doc comment and also document
     add_bootloader_randomness() while we're at it.]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b44b759b625d4bd8d614da70885c18b282ea20fc
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Dec 23 00:09:57 2020 -0800

    crypto: blake2s - adjust include guard naming
    
    commit 8786841bc2020f7f2513a6c74e64912f07b9c0dc upstream.
    
    Use the full path in the include guards for the BLAKE2s headers to avoid
    ambiguity and to match the convention for most files in include/crypto/.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34dc98ce21995c838d26d56b4346e74c85343472
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Dec 23 00:09:58 2020 -0800

    crypto: blake2s - include <linux/bug.h> instead of <asm/bug.h>
    
    commit bbda6e0f1303953c855ee3669655a81b69fbe899 upstream.
    
    Address the following checkpatch warning:
    
            WARNING: Use #include <linux/bug.h> instead of <asm/bug.h>
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9404e8c983db03c620856e5c3f5267749d7bf718
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Nov 30 13:43:15 2021 -0500

    MAINTAINERS: co-maintain random.c
    
    commit 58e1100fdc5990b0cc0d4beaf2562a92e621ac7d upstream.
    
    random.c is a bit understaffed, and folks want more prompt reviews. I've
    got the crypto background and the interest to do these reviews, and have
    authored parts of the file already.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ab8e04f6da2696ece26579a5159d67a8d8574be
Author: Eric Biggers <ebiggers@google.com>
Date:   Sun Mar 21 22:14:00 2021 -0700

    random: remove dead code left over from blocking pool
    
    commit 118a4417e14348b2e46f5e467da8444ec4757a45 upstream.
    
    Remove some dead code that was left over following commit 90ea1c6436d2
    ("random: remove the blocking pool").
    
    Cc: linux-crypto@vger.kernel.org
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Jann Horn <jannh@google.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fb7c4dac63d1273b251599655c556d8004f9e7d
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Nov 5 16:29:44 2020 +0100

    random: avoid arch_get_random_seed_long() when collecting IRQ randomness
    
    commit 390596c9959c2a4f5b456df339f0604df3d55fe0 upstream.
    
    When reseeding the CRNG periodically, arch_get_random_seed_long() is
    called to obtain entropy from an architecture specific source if one
    is implemented. In most cases, these are special instructions, but in
    some cases, such as on ARM, we may want to back this using firmware
    calls, which are considerably more expensive.
    
    Another call to arch_get_random_seed_long() exists in the CRNG driver,
    in add_interrupt_randomness(), which collects entropy by capturing
    inter-interrupt timing and relying on interrupt jitter to provide
    random bits. This is done by keeping a per-CPU state, and mixing in
    the IRQ number, the cycle counter and the return address every time an
    interrupt is taken, and mixing this per-CPU state into the entropy pool
    every 64 invocations, or at least once per second. The entropy that is
    gathered this way is credited as 1 bit of entropy. Every time this
    happens, arch_get_random_seed_long() is invoked, and the result is
    mixed in as well, and also credited with 1 bit of entropy.
    
    This means that arch_get_random_seed_long() is called at least once
    per second on every CPU, which seems excessive, and doesn't really
    scale, especially in a virtualization scenario where CPUs may be
    oversubscribed: in cases where arch_get_random_seed_long() is backed
    by an instruction that actually goes back to a shared hardware entropy
    source (such as RNDRRS on ARM), we will end up hitting it hundreds of
    times per second.
    
    So let's drop the call to arch_get_random_seed_long() from
    add_interrupt_randomness(), and instead, rely on crng_reseed() to call
    the arch hook to get random seed material from the platform.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Tested-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://lore.kernel.org/r/20201105152944.16953-1-ardb@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aa1f386ebcf674165845f6e6bb2cacfc3bda5b3
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Mon Feb 10 13:00:13 2020 +0000

    random: add arch_get_random_*long_early()
    
    commit 253d3194c2b58152fe830fd27c2fd83ebc6fe5ee upstream.
    
    Some architectures (e.g. arm64) can have heterogeneous CPUs, and the
    boot CPU may be able to provide entropy while secondary CPUs cannot. On
    such systems, arch_get_random_long() and arch_get_random_seed_long()
    will fail unless support for RNG instructions has been detected on all
    CPUs. This prevents the boot CPU from being able to provide
    (potentially) trusted entropy when seeding the primary CRNG.
    
    To make it possible to seed the primary CRNG from the boot CPU without
    adversely affecting the runtime versions of arch_get_random_long() and
    arch_get_random_seed_long(), this patch adds new early versions of the
    functions used when initializing the primary CRNG.
    
    Default implementations are provided atop of the existing
    arch_get_random_long() and arch_get_random_seed_long() so that only
    architectures with such constraints need to provide the new helpers.
    
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Link: https://lore.kernel.org/r/20200210130015.17664-3-mark.rutland@arm.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d80af75c13cb6e33bcb2a62cd92319e28fc7ebc
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:20 2020 +0000

    powerpc: Use bool in archrandom.h
    
    commit 98dcfce69729f9ce0fb14f96a39bbdba21429597 upstream.
    
    The generic interface uses bool not int; match that.
    
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-9-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4682b96e868b6e7d48cb49f6df22a50bb11efbf0
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:18 2020 +0000

    linux/random.h: Mark CONFIG_ARCH_RANDOM functions __must_check
    
    commit 904caa6413c87aacbf7d0682da617c39ca18cf1a upstream.
    
    We must not use the pointer output without validating the
    success of the random read.
    
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-7-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7d3392a0ded4bed19d8e73ac7181039bcfeb5f5
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:17 2020 +0000

    linux/random.h: Use false with bool
    
    commit 66f5ae899ada79c0e9a3d8d954f93a72344cd350 upstream.
    
    Keep the generic fallback versions in sync with the other architecture
    specific implementations and use the proper name for false.
    
    Suggested-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-6-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cacc99ee5a9c15923a74ff6942d8710c674e51f5
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:16 2020 +0000

    linux/random.h: Remove arch_has_random, arch_has_random_seed
    
    commit 647f50d5d9d933b644b29c54f13ac52af1b1774d upstream.
    
    The arm64 version of archrandom.h will need to be able to test for
    support and read the random number without preemption, so a separate
    query predicate is not practical.
    
    Since this part of the generic interface is unused, remove it.
    
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-5-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 596bcf5911e619da50c2174e234a0f8363c70a94
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:15 2020 +0000

    s390: Remove arch_has_random, arch_has_random_seed
    
    commit 5e054c820f59bbb9714d5767f5f476581c309ca8 upstream.
    
    These symbols are currently part of the generic archrandom.h
    interface, but are currently unused and can be removed.
    
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-4-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cb0d7df9bdbedf9ce0ed30bf22410eccf977530
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:14 2020 +0000

    powerpc: Remove arch_has_random, arch_has_random_seed
    
    commit cbac004995a0ce8453bdc555fab579e2bdb842a6 upstream.
    
    These symbols are currently part of the generic archrandom.h
    interface, but are currently unused and can be removed.
    
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-3-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ebd5da615c028e3bcd01bb6b6f7ef8a3099b38b
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 10 14:54:13 2020 +0000

    x86: Remove arch_has_random, arch_has_random_seed
    
    commit 5f2ed7f5b99b54389b74e53309677831ac9cb9d7 upstream.
    
    Use the expansion of these macros directly in arch_get_random_*.
    
    These symbols are currently part of the generic archrandom.h
    interface, but are currently unused and can be removed.
    
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20200110145422.49141-2-broonie@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5948834b0c42269bd96c99ad9be34d6d5f456b2
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Mar 10 12:09:12 2020 +0000

    random: avoid warnings for !CONFIG_NUMA builds
    
    commit ab9a7e27044b87ff2be47b8f8e095400e7fccc44 upstream.
    
    As crng_initialize_secondary() is only called by do_numa_crng_init(),
    and the latter is under ifdeffery for CONFIG_NUMA, when CONFIG_NUMA is
    not selected the compiler will warn that the former is unused:
    
    | drivers/char/random.c:820:13: warning: 'crng_initialize_secondary' defined but not used [-Wunused-function]
    |   820 | static void crng_initialize_secondary(struct crng_state *crng)
    |       |             ^~~~~~~~~~~~~~~~~~~~~~~~~
    
    Stephen reports that this happens for x86_64 noallconfig builds.
    
    We could move crng_initialize_secondary() and crng_init_try_arch() under
    the CONFIG_NUMA ifdeffery, but this has the unfortunate property of
    separating them from crng_initialize_primary() and
    crng_init_try_arch_early() respectively. Instead, let's mark
    crng_initialize_secondary() as __maybe_unused.
    
    Link: https://lore.kernel.org/r/20200310121747.GA49602@lakrids.cambridge.arm.com
    Fixes: 5cbe0f13b51a ("random: split primary/secondary crng init paths")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0a6d6a76a2fe799833ed60072c8e04adcc9542c
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Mon Feb 10 13:00:12 2020 +0000

    random: split primary/secondary crng init paths
    
    commit 5cbe0f13b51ac2fb2fd55902cff8d0077fc084c0 upstream.
    
    Currently crng_initialize() is used for both the primary CRNG and
    secondary CRNGs. While we wish to share common logic, we need to do a
    number of additional things for the primary CRNG, and this would be
    easier to deal with were these handled in separate functions.
    
    This patch splits crng_initialize() into crng_initialize_primary() and
    crng_initialize_secondary(), with common logic factored out into a
    crng_init_try_arch() helper.
    
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Link: https://lore.kernel.org/r/20200210130015.17664-2-mark.rutland@arm.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03fafcef471a8102d5eee7a2f70e125b996dfa33
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Tue Jan 7 16:56:11 2020 -0500

    random: remove some dead code of poolinfo
    
    commit 09a6d00a42ce0e63e2a15be3d070974bcc656ec7 upstream.
    
    Since it is not being used, so delete it.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Link: https://lore.kernel.org/r/20190607182517.28266-5-tiny.windzz@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a15f8c15ed9792ea04626c2dbe7b3f5da7672ab5
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Tue Jan 7 16:55:34 2020 -0500

    random: fix typo in add_timer_randomness()
    
    commit 727d499a6f4f29b6abdb635032f5e53e5905aedb upstream.
    
    s/entimate/estimate
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Link: https://lore.kernel.org/r/20190607182517.28266-4-tiny.windzz@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8edfa1c6c05b18a1ab254e164575fedee456b210
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Fri Jun 7 14:25:15 2019 -0400

    random: Add and use pr_fmt()
    
    commit 12cd53aff5ea0359b1dac91fcd9ddc7b9e646588 upstream.
    
    Prefix all printk/pr_<level> messages with "random: " to make the
    logging a bit more consistent.
    
    Miscellanea:
    
    o Convert a printks to pr_notice
    o Whitespace to align to open parentheses
    o Remove embedded "random: " from pr_* as pr_fmt adds it
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Link: https://lore.kernel.org/r/20190607182517.28266-3-tiny.windzz@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5088389a9158c4a6a26b787fb614e1dc9e2b1139
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Fri Jun 7 14:25:14 2019 -0400

    random: convert to ENTROPY_BITS for better code readability
    
    commit 12faac30d157970fdbfa171bbeb1fb88350303b1 upstream.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Link: https://lore.kernel.org/r/20190607182517.28266-2-tiny.windzz@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea13b4ac6a312c616ab5054624dc4f26dea18570
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Tue Jan 7 16:10:28 2020 -0500

    random: remove unnecessary unlikely()
    
    commit 870e05b1b18814911cb2703a977f447cb974f0f9 upstream.
    
    WARN_ON() already contains an unlikely(), so it's not necessary to use
    unlikely.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Link: https://lore.kernel.org/r/20190607182517.28266-1-tiny.windzz@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 051278bf8997967730bc47faa1d251e5b36a6ea4
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:51 2019 -0800

    random: remove kernel.random.read_wakeup_threshold
    
    commit c95ea0c69ffda19381c116db2be23c7e654dac98 upstream.
    
    It has no effect any more, so remove it.  We can revert this if
    there is some user code that expects to be able to set this sysctl.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/a74ed2cf0b5a5451428a246a9239f5bc4e29358f.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ae32ecd83154f5b9c3f30dc0ba3db77f29f7f6a
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:50 2019 -0800

    random: delete code to pull data into pools
    
    commit 84df7cdfbb215a34657b39f4257dab739efa2df9 upstream.
    
    There is no pool that pulls, so it was just dead code.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/4a05fe0c7a5c831389ef4aea51d24528ac8682c7.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba17344096ae6f7318651a198732370b15bc7b9c
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:49 2019 -0800

    random: remove the blocking pool
    
    commit 90ea1c6436d26e62496616fb5891e00819ff4849 upstream.
    
    There is no longer any interface to read data from the blocking
    pool, so remove it.
    
    This enables quite a bit of code deletion, much of which will be
    done in subsequent patches.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/511225a224bf0a291149d3c0b8b45393cd03ab96.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5eadd290e1706e6937ecb7b825882f6a0b971e80
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Wed Dec 29 22:10:03 2021 +0100

    random: fix crash on multiple early calls to add_bootloader_randomness()
    
    commit f7e67b8e803185d0aabe7f29d25a35c8be724a78 upstream.
    
    Currently, if CONFIG_RANDOM_TRUST_BOOTLOADER is enabled, multiple calls
    to add_bootloader_randomness() are broken and can cause a NULL pointer
    dereference, as noted by Ivan T. Ivanov. This is not only a hypothetical
    problem, as qemu on arm64 may provide bootloader entropy via EFI and via
    devicetree.
    
    On the first call to add_hwgenerator_randomness(), crng_fast_load() is
    executed, and if the seed is long enough, crng_init will be set to 1.
    On subsequent calls to add_bootloader_randomness() and then to
    add_hwgenerator_randomness(), crng_fast_load() will be skipped. Instead,
    wait_event_interruptible() and then credit_entropy_bits() will be called.
    If the entropy count for that second seed is large enough, that proceeds
    to crng_reseed().
    
    However, both wait_event_interruptible() and crng_reseed() depends
    (at least in numa_crng_init()) on workqueues. Therefore, test whether
    system_wq is already initialized, which is a sufficient indicator that
    workqueue_init_early() has progressed far enough.
    
    If we wind up hitting the !system_wq case, we later want to do what
    would have been done there when wqs are up, so set a flag, and do that
    work later from the rand_initialize() call.
    
    Reported-by: Ivan T. Ivanov <iivanov@suse.de>
    Fixes: 18b915ac6b0a ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    [Jason: added crng_need_done state and related logic.]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64bfe2ee56743d95e4cfa43af6d27d2c675edfc4
Author: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date:   Wed Nov 13 16:16:25 2019 -0500

    char/random: silence a lockdep splat with printk()
    
    [ Upstream commit 1b710b1b10eff9d46666064ea25f079f70bc67a8 ]
    
    Sergey didn't like the locking order,
    
    uart_port->lock  ->  tty_port->lock
    
    uart_write (uart_port->lock)
      __uart_start
        pl011_start_tx
          pl011_tx_chars
            uart_write_wakeup
              tty_port_tty_wakeup
                tty_port_default
                  tty_port_tty_get (tty_port->lock)
    
    but those code is so old, and I have no clue how to de-couple it after
    checking other locks in the splat. There is an onging effort to make all
    printk() as deferred, so until that happens, workaround it for now as a
    short-term fix.
    
    LTP: starting iogen01 (export LTPROOT; rwtest -N iogen01 -i 120s -s
    read,write -Da -Dv -n 2 500b:$TMPDIR/doio.f1.$$
    1000b:$TMPDIR/doio.f2.$$)
    WARNING: possible circular locking dependency detected
    ------------------------------------------------------
    doio/49441 is trying to acquire lock:
    ffff008b7cff7290 (&(&zone->lock)->rlock){..-.}, at: rmqueue+0x138/0x2050
    
    but task is already holding lock:
    60ff000822352818 (&pool->lock/1){-.-.}, at: start_flush_work+0xd8/0x3f0
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #4 (&pool->lock/1){-.-.}:
           lock_acquire+0x320/0x360
           _raw_spin_lock+0x64/0x80
           __queue_work+0x4b4/0xa10
           queue_work_on+0xac/0x11c
           tty_schedule_flip+0x84/0xbc
           tty_flip_buffer_push+0x1c/0x28
           pty_write+0x98/0xd0
           n_tty_write+0x450/0x60c
           tty_write+0x338/0x474
           __vfs_write+0x88/0x214
           vfs_write+0x12c/0x1a4
           redirected_tty_write+0x90/0xdc
           do_loop_readv_writev+0x140/0x180
           do_iter_write+0xe0/0x10c
           vfs_writev+0x134/0x1cc
           do_writev+0xbc/0x130
           __arm64_sys_writev+0x58/0x8c
           el0_svc_handler+0x170/0x240
           el0_sync_handler+0x150/0x250
           el0_sync+0x164/0x180
    
      -> #3 (&(&port->lock)->rlock){-.-.}:
           lock_acquire+0x320/0x360
           _raw_spin_lock_irqsave+0x7c/0x9c
           tty_port_tty_get+0x24/0x60
           tty_port_default_wakeup+0x1c/0x3c
           tty_port_tty_wakeup+0x34/0x40
           uart_write_wakeup+0x28/0x44
           pl011_tx_chars+0x1b8/0x270
           pl011_start_tx+0x24/0x70
           __uart_start+0x5c/0x68
           uart_write+0x164/0x1c8
           do_output_char+0x33c/0x348
           n_tty_write+0x4bc/0x60c
           tty_write+0x338/0x474
           redirected_tty_write+0xc0/0xdc
           do_loop_readv_writev+0x140/0x180
           do_iter_write+0xe0/0x10c
           vfs_writev+0x134/0x1cc
           do_writev+0xbc/0x130
           __arm64_sys_writev+0x58/0x8c
           el0_svc_handler+0x170/0x240
           el0_sync_handler+0x150/0x250
           el0_sync+0x164/0x180
    
      -> #2 (&port_lock_key){-.-.}:
           lock_acquire+0x320/0x360
           _raw_spin_lock+0x64/0x80
           pl011_console_write+0xec/0x2cc
           console_unlock+0x794/0x96c
           vprintk_emit+0x260/0x31c
           vprintk_default+0x54/0x7c
           vprintk_func+0x218/0x254
           printk+0x7c/0xa4
           register_console+0x734/0x7b0
           uart_add_one_port+0x734/0x834
           pl011_register_port+0x6c/0xac
           sbsa_uart_probe+0x234/0x2ec
           platform_drv_probe+0xd4/0x124
           really_probe+0x250/0x71c
           driver_probe_device+0xb4/0x200
           __device_attach_driver+0xd8/0x188
           bus_for_each_drv+0xbc/0x110
           __device_attach+0x120/0x220
           device_initial_probe+0x20/0x2c
           bus_probe_device+0x54/0x100
           device_add+0xae8/0xc2c
           platform_device_add+0x278/0x3b8
           platform_device_register_full+0x238/0x2ac
           acpi_create_platform_device+0x2dc/0x3a8
           acpi_bus_attach+0x390/0x3cc
           acpi_bus_attach+0x108/0x3cc
           acpi_bus_attach+0x108/0x3cc
           acpi_bus_attach+0x108/0x3cc
           acpi_bus_scan+0x7c/0xb0
           acpi_scan_init+0xe4/0x304
           acpi_init+0x100/0x114
           do_one_initcall+0x348/0x6a0
           do_initcall_level+0x190/0x1fc
           do_basic_setup+0x34/0x4c
           kernel_init_freeable+0x19c/0x260
           kernel_init+0x18/0x338
           ret_from_fork+0x10/0x18
    
      -> #1 (console_owner){-...}:
           lock_acquire+0x320/0x360
           console_lock_spinning_enable+0x6c/0x7c
           console_unlock+0x4f8/0x96c
           vprintk_emit+0x260/0x31c
           vprintk_default+0x54/0x7c
           vprintk_func+0x218/0x254
           printk+0x7c/0xa4
           get_random_u64+0x1c4/0x1dc
           shuffle_pick_tail+0x40/0xac
           __free_one_page+0x424/0x710
           free_one_page+0x70/0x120
           __free_pages_ok+0x61c/0xa94
           __free_pages_core+0x1bc/0x294
           memblock_free_pages+0x38/0x48
           __free_pages_memory+0xcc/0xfc
           __free_memory_core+0x70/0x78
           free_low_memory_core_early+0x148/0x18c
           memblock_free_all+0x18/0x54
           mem_init+0xb4/0x17c
           mm_init+0x14/0x38
           start_kernel+0x19c/0x530
    
      -> #0 (&(&zone->lock)->rlock){..-.}:
           validate_chain+0xf6c/0x2e2c
           __lock_acquire+0x868/0xc2c
           lock_acquire+0x320/0x360
           _raw_spin_lock+0x64/0x80
           rmqueue+0x138/0x2050
           get_page_from_freelist+0x474/0x688
           __alloc_pages_nodemask+0x3b4/0x18dc
           alloc_pages_current+0xd0/0xe0
           alloc_slab_page+0x2b4/0x5e0
           new_slab+0xc8/0x6bc
           ___slab_alloc+0x3b8/0x640
           kmem_cache_alloc+0x4b4/0x588
           __debug_object_init+0x778/0x8b4
           debug_object_init_on_stack+0x40/0x50
           start_flush_work+0x16c/0x3f0
           __flush_work+0xb8/0x124
           flush_work+0x20/0x30
           xlog_cil_force_lsn+0x88/0x204 [xfs]
           xfs_log_force_lsn+0x128/0x1b8 [xfs]
           xfs_file_fsync+0x3c4/0x488 [xfs]
           vfs_fsync_range+0xb0/0xd0
           generic_write_sync+0x80/0xa0 [xfs]
           xfs_file_buffered_aio_write+0x66c/0x6e4 [xfs]
           xfs_file_write_iter+0x1a0/0x218 [xfs]
           __vfs_write+0x1cc/0x214
           vfs_write+0x12c/0x1a4
           ksys_write+0xb0/0x120
           __arm64_sys_write+0x54/0x88
           el0_svc_handler+0x170/0x240
           el0_sync_handler+0x150/0x250
           el0_sync+0x164/0x180
    
           other info that might help us debug this:
    
     Chain exists of:
       &(&zone->lock)->rlock --> &(&port->lock)->rlock --> &pool->lock/1
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&pool->lock/1);
                                   lock(&(&port->lock)->rlock);
                                   lock(&pool->lock/1);
      lock(&(&zone->lock)->rlock);
    
                    *** DEADLOCK ***
    
    4 locks held by doio/49441:
     #0: a0ff00886fc27408 (sb_writers#8){.+.+}, at: vfs_write+0x118/0x1a4
     #1: 8fff00080810dfe0 (&xfs_nondir_ilock_class){++++}, at:
    xfs_ilock+0x2a8/0x300 [xfs]
     #2: ffff9000129f2390 (rcu_read_lock){....}, at:
    rcu_lock_acquire+0x8/0x38
     #3: 60ff000822352818 (&pool->lock/1){-.-.}, at:
    start_flush_work+0xd8/0x3f0
    
                   stack backtrace:
    CPU: 48 PID: 49441 Comm: doio Tainted: G        W
    Hardware name: HPE Apollo 70             /C01_APACHE_MB         , BIOS
    L50_5.13_1.11 06/18/2019
    Call trace:
     dump_backtrace+0x0/0x248
     show_stack+0x20/0x2c
     dump_stack+0xe8/0x150
     print_circular_bug+0x368/0x380
     check_noncircular+0x28c/0x294
     validate_chain+0xf6c/0x2e2c
     __lock_acquire+0x868/0xc2c
     lock_acquire+0x320/0x360
     _raw_spin_lock+0x64/0x80
     rmqueue+0x138/0x2050
     get_page_from_freelist+0x474/0x688
     __alloc_pages_nodemask+0x3b4/0x18dc
     alloc_pages_current+0xd0/0xe0
     alloc_slab_page+0x2b4/0x5e0
     new_slab+0xc8/0x6bc
     ___slab_alloc+0x3b8/0x640
     kmem_cache_alloc+0x4b4/0x588
     __debug_object_init+0x778/0x8b4
     debug_object_init_on_stack+0x40/0x50
     start_flush_work+0x16c/0x3f0
     __flush_work+0xb8/0x124
     flush_work+0x20/0x30
     xlog_cil_force_lsn+0x88/0x204 [xfs]
     xfs_log_force_lsn+0x128/0x1b8 [xfs]
     xfs_file_fsync+0x3c4/0x488 [xfs]
     vfs_fsync_range+0xb0/0xd0
     generic_write_sync+0x80/0xa0 [xfs]
     xfs_file_buffered_aio_write+0x66c/0x6e4 [xfs]
     xfs_file_write_iter+0x1a0/0x218 [xfs]
     __vfs_write+0x1cc/0x214
     vfs_write+0x12c/0x1a4
     ksys_write+0xb0/0x120
     __arm64_sys_write+0x54/0x88
     el0_svc_handler+0x170/0x240
     el0_sync_handler+0x150/0x250
     el0_sync+0x164/0x180
    
    Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Signed-off-by: Qian Cai <cai@lca.pw>
    Link: https://lore.kernel.org/r/1573679785-21068-1-git-send-email-cai@lca.pw
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9aefae44f37ef9df5eae0ea4dadd75a3053fd9ff
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:48 2019 -0800

    random: make /dev/random be almost like /dev/urandom
    
    commit 30c08efec8884fb106b8e57094baa51bb4c44e32 upstream.
    
    This patch changes the read semantics of /dev/random to be the same
    as /dev/urandom except that reads will block until the CRNG is
    ready.
    
    None of the cleanups that this enables have been done yet.  As a
    result, this gives a warning about an unused function.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/5e6ac8831c6cf2e56a7a4b39616d1732b2bdd06c.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa38e379f95e5c4fc5a6eff48f5d73aac1422986
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:47 2019 -0800

    random: ignore GRND_RANDOM in getentropy(2)
    
    commit 48446f198f9adcb499b30332488dfd5bc3f176f6 upstream.
    
    The separate blocking pool is going away.  Start by ignoring
    GRND_RANDOM in getentropy(2).
    
    This should not materially break any API.  Any code that worked
    without this change should work at least as well with this change.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/705c5a091b63cc5da70c99304bb97e0109be0a26.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7b5560f065e7ef2ff0482dc0c8a79aca7f767b1
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:46 2019 -0800

    random: add GRND_INSECURE to return best-effort non-cryptographic bytes
    
    commit 75551dbf112c992bc6c99a972990b3f272247e23 upstream.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/d5473b56cf1fa900ca4bd2b3fc1e5b8874399919.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32d4b398c078bc2859dcc1f5e11b89ab0b34ab76
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:45 2019 -0800

    random: Add a urandom_read_nowait() for random APIs that don't warn
    
    commit c6f1deb158789abba02a7eba600747843eeb3a57 upstream.
    
    /dev/random and getrandom() never warn.  Split the meat of
    urandom_read() into urandom_read_nowarn() and leave the warning code
    in urandom_read().
    
    This has no effect on kernel behavior, but it makes subsequent
    patches more straightforward.  It also makes the fact that
    getrandom() never warns more obvious.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/c87ab200588de746431d9f916501ef11e5242b13.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a8e277bf9ccf2a87ed46036cf6040df3648ee31
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Dec 23 00:20:44 2019 -0800

    random: Don't wake crng_init_wait when crng_init == 1
    
    commit 4c8d062186d9923c09488716b2fb1b829b5b8006 upstream.
    
    crng_init_wait is only used to wayt for crng_init to be set to 2, so
    there's no point to waking it when crng_init is set to 1.  Remove the
    unnecessary wake_up_interruptible() call.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Link: https://lore.kernel.org/r/6fbc0bfcbfc1fa2c76fd574f5b6f552b11be7fde.1577088521.git.luto@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42b10f6770ed1e41c1021a4f9b477468f7ff6859
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jan 11 18:58:43 2022 +0100

    lib/crypto: sha1: re-roll loops to reduce code size
    
    commit 9a1536b093bb5bf60689021275fd24d513bb8db0 upstream.
    
    With SHA-1 no longer being used for anything performance oriented, and
    also soon to be phased out entirely, we can make up for the space added
    by unrolled BLAKE2s by simply re-rolling SHA-1. Since SHA-1 is so much
    more complex, re-rolling it more or less takes care of the code size
    added by BLAKE2s. And eventually, hopefully we'll see SHA-1 removed
    entirely from most small kernel builds.
    
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66680715fd7b069dc6cd113c77e10311afe04276
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jan 11 14:37:41 2022 +0100

    lib/crypto: blake2s: move hmac construction into wireguard
    
    commit d8d83d8ab0a453e17e68b3a3bed1f940c34b8646 upstream.
    
    Basically nobody should use blake2s in an HMAC construction; it already
    has a keyed variant. But unfortunately for historical reasons, Noise,
    used by WireGuard, uses HKDF quite strictly, which means we have to use
    this. Because this really shouldn't be used by others, this commit moves
    it into wireguard's noise.c locally, so that kernels that aren't using
    WireGuard don't get this superfluous code baked in. On m68k systems,
    this shaves off ~314 bytes.
    
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    [Jason: for stable, skip the wireguard changes, since this kernel
     doesn't have wireguard.]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6adb419f06ffd185cbca84781846fe6054cf3d8e
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Nov 8 13:22:28 2019 +0100

    crypto: blake2s - generic C library implementation and selftest
    
    commit 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28 upstream.
    
    The C implementation was originally based on Samuel Neves' public
    domain reference implementation but has since been heavily modified
    for the kernel. We're able to do compile-time optimizations by moving
    some scaffolding around the final function into the header file.
    
    Information: https://blake2.net/
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
    Co-developed-by: Samuel Neves <sneves@dei.uc.pt>
    [ardb: - move from lib/zinc to lib/crypto
           - remove simd handling
           - rewrote selftest for better coverage
           - use fixed digest length for blake2s_hmac() and rename to
             blake2s256_hmac() ]
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [Jason: for stable, skip kconfig and wire up directly, and skip the arch
     hooks; optimized implementations need not be backported.]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a83bdc0830f6b421384dd15e812de68d70773600
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Mar 21 19:01:40 2018 +0200

    crypto: Deduplicate le32_to_cpu_array() and cpu_to_le32_array()
    
    commit 9def051018c08e65c532822749e857eb4b2e12e7 upstream.
    
    Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them
    to the generic header.
    
    No functional change implied.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7c853adcdfa248f6262df0cdbc48600f1cdc752
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sun Nov 17 08:48:17 2019 +0800

    Revert "hwrng: core - Freeze khwrng thread during suspend"
    
    commit 08e97aec700aeff54c4847f170e566cbd7e14e81 upstream.
    
    This reverts commit 03a3bb7ae631 ("hwrng: core - Freeze khwrng
    thread during suspend"), ff296293b353 ("random: Support freezable
    kthreads in add_hwgenerator_randomness()") and 59b569480dc8 ("random:
    Use wait_event_freezable() in add_hwgenerator_randomness()").
    
    These patches introduced regressions and we need more time to
    get them ready for mainline.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ea167431f404da5593960f1b74866924f13af61
Author: Borislav Petkov <bp@alien8.de>
Date:   Tue Oct 1 19:50:23 2019 +0200

    char/random: Add a newline at the end of the file
    
    commit 3fd57e7a9e66b9a8bcbf0560ff09e84d0b8de1bd upstream.
    
    On Tue, Oct 01, 2019 at 10:14:40AM -0700, Linus Torvalds wrote:
    > The previous state of the file didn't have that 0xa at the end, so you get that
    >
    >
    >   -EXPORT_SYMBOL_GPL(add_bootloader_randomness);
    >   \ No newline at end of file
    >   +EXPORT_SYMBOL_GPL(add_bootloader_randomness);
    >
    > which is "the '-' line doesn't have a newline, the '+' line does" marker.
    
    Aaha, that makes total sense, thanks for explaining. Oh well, let's fix
    it then so that people don't scratch heads like me.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1f7c9876ef10c53cbcb0a011cf342c1289d9c94
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Thu Sep 5 09:41:12 2019 -0700

    random: Use wait_event_freezable() in add_hwgenerator_randomness()
    
    commit 59b569480dc8bb9dce57cdff133853a842dfd805 upstream.
    
    Sebastian reports that after commit ff296293b353 ("random: Support freezable
    kthreads in add_hwgenerator_randomness()") we can call might_sleep() when the
    task state is TASK_INTERRUPTIBLE (state=1). This leads to the following warning.
    
     do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000349d1489>] prepare_to_wait_event+0x5a/0x180
     WARNING: CPU: 0 PID: 828 at kernel/sched/core.c:6741 __might_sleep+0x6f/0x80
     Modules linked in:
    
     CPU: 0 PID: 828 Comm: hwrng Not tainted 5.3.0-rc7-next-20190903+ #46
     RIP: 0010:__might_sleep+0x6f/0x80
    
     Call Trace:
      kthread_freezable_should_stop+0x1b/0x60
      add_hwgenerator_randomness+0xdd/0x130
      hwrng_fillfn+0xbf/0x120
      kthread+0x10c/0x140
      ret_from_fork+0x27/0x50
    
    We shouldn't call kthread_freezable_should_stop() from deep within the
    wait_event code because the task state is still set as
    TASK_INTERRUPTIBLE instead of TASK_RUNNING and
    kthread_freezable_should_stop() will try to call into the freezer with
    the task in the wrong state. Use wait_event_freezable() instead so that
    it calls schedule() in the right place and tries to enter the freezer
    when the task state is TASK_RUNNING instead.
    
    Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Keerthy <j-keerthy@ti.com>
    Fixes: ff296293b353 ("random: Support freezable kthreads in add_hwgenerator_randomness()")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb1e322c70cecf656acaeda1f4b52922cc610211
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Fri Aug 23 14:24:51 2019 +0800

    fdt: add support for rng-seed
    
    commit 428826f5358c922dc378830a1717b682c0823160 upstream.
    
    Introducing a chosen node, rng-seed, which is an entropy that can be
    passed to kernel called very early to increase initial device
    randomness. Bootloader should provide this entropy and the value is
    read from /chosen/rng-seed in DT.
    
    Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(),
    since early_init_dt_scan_chosen() would modify fdt to erase rng-seed.
    
    Add a new interface add_bootloader_randomness() for rng-seed use case.
    Depends on whether the seed is trustworthy, rng seed would be passed to
    add_hwgenerator_randomness(). Otherwise it would be passed to
    add_device_randomness(). Decision is controlled by kernel config
    RANDOM_TRUST_BOOTLOADER.
    
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Theodore Ts'o <tytso@mit.edu> # drivers/char/random.c
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b33f93df879347751da3a7575b825dbe7f7d2e5
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Mon Aug 19 08:02:45 2019 -0700

    random: Support freezable kthreads in add_hwgenerator_randomness()
    
    commit ff296293b3538d19278a7f7cd1f3aa600ad9164c upstream.
    
    The kthread calling this function is freezable after commit 03a3bb7ae631
    ("hwrng: core - Freeze khwrng thread during suspend") is applied.
    Unfortunately, this function uses wait_event_interruptible() but doesn't
    check for the kthread being woken up by the fake freezer signal. When a
    user suspends the system, this kthread will wake up and if it fails the
    entropy size check it will immediately go back to sleep and not go into
    the freezer. Eventually, suspend will fail because the task never froze
    and a warning message like this may appear:
    
     PM: suspend entry (deep)
     Filesystems sync: 0.000 seconds
     Freezing user space processes ... (elapsed 0.001 seconds) done.
     OOM killer disabled.
     Freezing remaining freezable tasks ...
     Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
     hwrng           R  running task        0   289      2 0x00000020
     [<c08c64c4>] (__schedule) from [<c08c6a10>] (schedule+0x3c/0xc0)
     [<c08c6a10>] (schedule) from [<c05dbd8c>] (add_hwgenerator_randomness+0xb0/0x100)
     [<c05dbd8c>] (add_hwgenerator_randomness) from [<bf1803c8>] (hwrng_fillfn+0xc0/0x14c [rng_core])
     [<bf1803c8>] (hwrng_fillfn [rng_core]) from [<c015abec>] (kthread+0x134/0x148)
     [<c015abec>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
    
    Check for a freezer signal here and skip adding any randomness if the
    task wakes up because it was frozen. This should make the kthread freeze
    properly and suspend work again.
    
    Fixes: 03a3bb7ae631 ("hwrng: core - Freeze khwrng thread during suspend")
    Reported-by: Keerthy <j-keerthy@ti.com>
    Tested-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaabe771c1aa52872fed8540d342a99fbe053f2f
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed May 22 12:02:16 2019 -0400

    random: fix soft lockup when trying to read from an uninitialized blocking pool
    
    commit 58be0106c5306b939b07b4b8bf00669a20593f4b upstream.
    
    Fixes: eb9d1bf079bb: "random: only read from /dev/random after its pool has received 128 bits"
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 138b6da69f9919da672191d2754d997b401c8163
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue May 7 16:28:15 2019 +0200

    latent_entropy: avoid build error when plugin cflags are not set
    
    commit 7e756f423af808b6571fed3144747db2ef7fa1c5 upstream.
    
    Some architectures set up CFLAGS for linux decompressor phase from
    scratch and do not include GCC_PLUGINS_CFLAGS. Since "latent_entropy"
    variable declaration is generated by the plugin code itself including
    linux/random.h in decompressor code then would cause a build
    error. E.g. on s390:
    
    In file included from ./include/linux/net.h:22,
                     from ./include/linux/skbuff.h:29,
                     from ./include/linux/if_ether.h:23,
                     from ./arch/s390/include/asm/diag.h:12,
                     from arch/s390/boot/startup.c:8:
    ./include/linux/random.h: In function 'add_latent_entropy':
    ./include/linux/random.h:26:39: error: 'latent_entropy' undeclared
    (first use in this function); did you mean 'add_latent_entropy'?
       26 |  add_device_randomness((const void *)&latent_entropy,
          |                                       ^~~~~~~~~~~~~~
          |                                       add_latent_entropy
    ./include/linux/random.h:26:39: note: each undeclared identifier is
    reported only once for each function it appears in
    
    The build error is triggered by commit a80313ff91ab ("s390/kernel:
    introduce .dma sections") which made it into 5.2 merge window.
    
    To address that avoid using CONFIG_GCC_PLUGIN_LATENT_ENTROPY in
    favour of LATENT_ENTROPY_PLUGIN definition which is defined as a
    part of gcc plugins cflags and hence reflect more accurately when gcc
    plugin is active. Besides that it is also used for similar purpose in
    linux/compiler-gcc.h for latent_entropy attribute definition.
    
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b30c2834aa404c923c2b567a61df8a3b352093de
Author: George Spelvin <lkml@sdf.org>
Date:   Fri Apr 19 23:48:20 2019 -0400

    random: document get_random_int() family
    
    commit 92e507d216139b356a375afbda2824e85235e748 upstream.
    
    Explain what these functions are for and when they offer
    an advantage over get_random_bytes().
    
    (We still need documentation on rng_is_initialized(), the
    random_ready_callback system, and early boot in general.)
    
    Signed-off-by: George Spelvin <lkml@sdf.org>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50622066f5d13aae559ddb414d7444cde7f113b5
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Apr 19 23:27:05 2019 -0400

    random: move rand_initialize() earlier
    
    commit d55535232c3dbde9a523a9d10d68670f5fe5dec3 upstream.
    
    Right now rand_initialize() is run as an early_initcall(), but it only
    depends on timekeeping_init() (for mixing ktime_get_real() into the
    pools). However, the call to boot_init_stack_canary() for stack canary
    initialization runs earlier, which triggers a warning at boot:
    
    random: get_random_bytes called from start_kernel+0x357/0x548 with crng_init=0
    
    Instead, this moves rand_initialize() to after timekeeping_init(), and moves
    canary initialization here as well.
    
    Note that this warning may still remain for machines that do not have
    UEFI RNG support (which initializes the RNG pools during setup_arch()),
    or for x86 machines without RDRAND (or booting without "random.trust=on"
    or CONFIG_RANDOM_TRUST_CPU=y).
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd5e41d61e3796f67877ec0b629fb423d8ec13a8
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Feb 20 16:06:38 2019 -0500

    random: only read from /dev/random after its pool has received 128 bits
    
    commit eb9d1bf079bb438d1a066d72337092935fc770f6 upstream.
    
    Immediately after boot, we allow reads from /dev/random before its
    entropy pool has been fully initialized.  Fix this so that we don't
    allow this until the blocking pool has received 128 bits.
    
    We do this by repurposing the initialized flag in the entropy pool
    struct, and use the initialized flag in the blocking pool to indicate
    whether it is safe to pull from the blocking pool.
    
    To do this, we needed to rework when we decide to push entropy from the
    input pool to the blocking pool, since the initialized flag for the
    input pool was used for this purpose.  To simplify things, we no
    longer use the initialized flag for that purpose, nor do we use the
    entropy_total field any more.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ed3248d0d6693c5c3d5821a64df718bb9b02b1
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Fri Nov 2 12:04:47 2018 +0100

    drivers/char/random.c: make primary_crng static
    
    commit 764ed189c82090c1d85f0e30636156736d8f09a8 upstream.
    
    Since the definition of struct crng_state is private to random.c, and
    primary_crng is neither declared or used elsewhere, there's no reason
    for that symbol to have external linkage.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14c55b81d99a67e03b36fd375c0502dba24197c7
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Fri Nov 2 12:04:46 2018 +0100

    drivers/char/random.c: remove unused stuct poolinfo::poolbits
    
    commit 3bd0b5bf7dc3ea02070fcbcd682ecf628269e8ef upstream.
    
    This field is never used, might as well remove it.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5d75e6df54a7f52b7e89bb191a2ed0729c3624e
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Fri Nov 2 12:04:45 2018 +0100

    drivers/char/random.c: constify poolinfo_table
    
    commit 26e0854ab3310bbeef1ed404a2c87132fc91f8e1 upstream.
    
    Never modified, might as well be put in .rodata.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08d453eca365ac4fd93b559662248108885d631e
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Aug 27 14:51:54 2018 -0700

    random: make CPU trust a boot parameter
    
    commit 9b25436662d5fb4c66eb527ead53cab15f596ee0 upstream.
    
    Instead of forcing a distro or other system builder to choose
    at build time whether the CPU is trusted for CRNG seeding via
    CONFIG_RANDOM_TRUST_CPU, provide a boot-time parameter for end users to
    control the choice. The CONFIG will set the default state instead.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4395f2316066cf6d6afc8788b9491d9168a060e2
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jul 31 21:11:00 2018 +0200

    random: Make crng state queryable
    
    commit 9a47249d444d344051c7c0e909fad0e88515a5c2 upstream.
    
    It is very useful to be able to know whether or not get_random_bytes_wait
    / wait_for_random_bytes is going to block or not, or whether plain
    get_random_bytes is going to return good randomness or bad randomness.
    
    The particular use case is for mitigating certain attacks in WireGuard.
    A handshake packet arrives and is queued up. Elsewhere a worker thread
    takes items from the queue and processes them. In replying to these
    items, it needs to use some random data, and it has to be good random
    data. If we simply block until we can have good randomness, then it's
    possible for an attacker to fill the queue up with packets waiting to be
    processed. Upon realizing the queue is full, WireGuard will detect that
    it's under a denial of service attack, and behave accordingly. A better
    approach is just to drop incoming handshake packets if the crng is not
    yet initialized.
    
    This patch, therefore, makes that information directly accessible.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6169849980907beb19311829b6753307911f8309
Author: Ingo Molnar <mingo@elte.hu>
Date:   Sun Jul 22 10:51:50 2018 -0400

    random: remove preempt disabled region
    
    commit b34fbaa9289328c7aec67d2b8b8b7d02bc61c67d upstream.
    
    No need to keep preemption disabled across the whole function.
    
    mix_pool_bytes() uses a spin_lock() to protect the pool and there are
    other places like write_pool() whhich invoke mix_pool_bytes() without
    disabling preemption.
    credit_entropy_bits() is invoked from other places like
    add_hwgenerator_randomness() without disabling preemption.
    
    Before commit 95b709b6be49 ("random: drop trickle mode") the function
    used __this_cpu_inc_return() which would require disabled preemption.
    The preempt_disable() section was added in commit 43d5d3018c37 ("[PATCH]
    random driver preempt robustness", history tree).  It was claimed that
    the code relied on "vt_ioctl() being called under BKL".
    
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bigeasy: enhance the commit message]
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 923eb78099e022db51884ef80bb589a21a30dd9e
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Jul 17 18:24:27 2018 -0400

    random: add a config option to trust the CPU's hwrng
    
    commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694 upstream.
    
    This gives the user building their own kernel (or a Linux
    distribution) the option of deciding whether or not to trust the CPU's
    hardware random number generator (e.g., RDRAND for x86 CPU's) as being
    correctly implemented and not having a back door introduced (perhaps
    courtesy of a Nation State's law enforcement or intelligence
    agencies).
    
    This will prevent getrandom(2) from blocking, if there is a
    willingness to trust the CPU manufacturer.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 005e7ac06d2b5e2994794efd700f5866beda4e54
Author: Tobin C. Harding <me@tobin.cc>
Date:   Fri Jun 22 09:15:32 2018 +1000

    random: Return nbytes filled from hw RNG
    
    commit 753d433b586d1d43c487e3d660f5778c7c8d58ea upstream.
    
    Currently the function get_random_bytes_arch() has return value 'void'.
    If the hw RNG fails we currently fall back to using get_random_bytes().
    This defeats the purpose of requesting random material from the hw RNG
    in the first place.
    
    There are currently no intree users of get_random_bytes_arch().
    
    Only get random bytes from the hw RNG, make function return the number
    of bytes retrieved from the hw RNG.
    
    Acked-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Tobin C. Harding <me@tobin.cc>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5572bef463953e88732a3f58fde14af425f635c
Author: Tobin C. Harding <me@tobin.cc>
Date:   Fri Jun 22 09:15:31 2018 +1000

    random: Fix whitespace pre random-bytes work
    
    commit 8ddd6efa56c3fe23df9fe4cf5e2b49cc55416ef4 upstream.
    
    There are a couple of whitespace issues around the function
    get_random_bytes_arch().  In preparation for patching this function
    let's clean them up.
    
    Acked-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Tobin C. Harding <me@tobin.cc>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3beefa251d34985e37ba11a18df6010a9b765ed2
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Thu Mar 1 00:22:47 2018 +0100

    drivers/char/random.c: remove unused dont_count_entropy
    
    commit 5e747dd9be54be190dd6ebeebf4a4a01ba765625 upstream.
    
    Ever since "random: kill dead extract_state struct" [1], the
    dont_count_entropy member of struct timer_rand_state has been
    effectively unused. Since it hasn't found a new use in 12 years, it's
    probably safe to finally kill it.
    
    [1] Pre-git, https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=c1c48e61c251f57e7a3f1bf11b3c462b2de9dcb5
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3146b90e3661b38dc24e64e9deea550ecc31b0c
Author: Andi Kleen <ak@linux.intel.com>
Date:   Wed Feb 28 13:43:28 2018 -0800

    random: optimize add_interrupt_randomness
    
    commit e8e8a2e47db6bb85bb0cb21e77b5c6aaedf864b4 upstream.
    
    add_interrupt_randomess always wakes up
    code blocking on /dev/random. This wake up is done
    unconditionally. Unfortunately this means all interrupts
    take the wait queue spinlock, which can be rather expensive
    on large systems processing lots of interrupts.
    
    We saw 1% cpu time spinning on this on a large macro workload
    running on a large system.
    
    I believe it's a recent regression (?)
    
    Always check if there is a waiter on the wait queue
    before waking up. This check can be done without
    taking a spinlock.
    
    1.06%         10460  [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
             |
             ---native_queued_spin_lock_slowpath
                |
                 --0.57%--_raw_spin_lock_irqsave
                           |
                            --0.56%--__wake_up_common_lock
                                      credit_entropy_bits
                                      add_interrupt_randomness
                                      handle_irq_event_percpu
                                      handle_irq_event
                                      handle_edge_irq
                                      handle_irq
                                      do_IRQ
                                      common_interrupt
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d218c093c864432fc6038682868f3d3c7c69e0cd
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Feb 4 23:07:46 2018 +0100

    random: always fill buffer in get_random_bytes_wait
    
    commit 25e3fca492035a2e1d4ac6e3b1edd9c1acd48897 upstream.
    
    In the unfortunate event that a developer fails to check the return
    value of get_random_bytes_wait, or simply wants to make a "best effort"
    attempt, for whatever that's worth, it's much better to still fill the
    buffer with _something_ rather than catastrophically failing in the case
    of an interruption. This is both a defense in depth measure against
    inevitable programming bugs, as well as a means of making the API a bit
    more useful.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f83ff022179e7ba4b5e14d96524fc0b74b6e3845
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Nov 22 11:51:39 2017 -0800

    crypto: chacha20 - Fix keystream alignment for chacha20_block()
    
    commit 9f480faec58cd6197a007ea1dcac6b7c3daf1139 upstream.
    
    When chacha20_block() outputs the keystream block, it uses 'u32' stores
    directly.  However, the callers (crypto/chacha20_generic.c and
    drivers/char/random.c) declare the keystream buffer as a 'u8' array,
    which is not guaranteed to have the needed alignment.
    
    Fix it by having both callers declare the keystream as a 'u32' array.
    For now this is preferable to switching over to the unaligned access
    macros because chacha20_block() is only being used in cases where we can
    easily control the alignment (stack buffers).
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0764df52607180d3b3712d698f491196731844b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Jan 31 14:37:39 2021 -0500

    9p: missing chunk of "fs/9p: Don't update file type when updating file attributes"
    
    commit b577d0cd2104fdfcf0ded3707540a12be8ddd8b0 upstream.
    
    In commit 45089142b149 Aneesh had missed one (admittedly, very unlikely
    to hit) case in v9fs_stat2inode_dotl().  However, the same considerations
    apply there as well - we have no business whatsoever to change ->i_rdev
    or the file type.
    
    Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>