Linux 5.4.200

 
9p: missing chunk of "fs/9p: Don't update file type when updating file attributes" [+ + +]
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>
 
alpha: define get_cycles macro for arch-override [+ + +]
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>

 
ALSA: hda/realtek - Add HW8326 support [+ + +]
Author: huangwenhui <huangwenhuia@uniontech.com>
Date:   Wed Jun 8 16:23:57 2022 +0800

    ALSA: hda/realtek - Add HW8326 support
    
    [ Upstream commit 527f4643e03c298c1e3321cfa27866b1374a55e1 ]
    
    Added the support of new Huawei codec HW8326. The HW8326 is developed
    by Huawei with Realtek's IP Core, and it's compatible with ALC256.
    
    Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
    Link: https://lore.kernel.org/r/20220608082357.26898-1-huangwenhuia@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: fix mute/micmute LEDs for HP 440 G8 [+ + +]
Author: Jeremy Szu <jeremy.szu@canonical.com>
Date:   Tue Mar 16 15:46:24 2021 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs for HP 440 G8
    
    commit e7d66cf799390166e90f9a5715f2eede4fe06d51 upstream.
    
    The HP EliteBook 840 G8 Notebook PC is using ALC236 codec which is
    using 0x02 to control mute LED and 0x01 to control micmute LED.
    Therefore, add a quirk to make it works.
    
    Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210316074626.79895-1-jeremy.szu@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machine [+ + +]
Author: Andy Chi <andy.chi@canonical.com>
Date:   Fri May 13 20:16:45 2022 +0800

    ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machine
    
    commit 024a7ad9eb4df626ca8c77fef4f67fd0ebd559d2 upstream.
    
    The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED
    and 0x01 to control micmute LED. Therefore, add a quirk to make it works.
    
    Signed-off-by: Andy Chi <andy.chi@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220513121648.28584-1-andy.chi@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: ftrace: fix branch range checks [+ + +]
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>

arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line [+ + +]
Author: Jean-Philippe Brucker <jean-philippe@linaro.org>
Date:   Tue Nov 3 14:49:01 2020 +0100

    arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line
    
    commit 7ee31a3aa8f490c6507bc4294df6b70bed1c593e upstream.
    
    Commit 36dadef23fcc ("kprobes: Init kprobes in early_initcall") enabled
    using kprobes from early_initcall. Unfortunately at this point the
    hardware debug infrastructure is not operational. The OS lock may still
    be locked, and the hardware watchpoints may have unknown values when
    kprobe enables debug monitors to single-step instructions.
    
    Rather than using hardware single-step, append a BRK instruction after
    the instruction to be executed out-of-line.
    
    Fixes: 36dadef23fcc ("kprobes: Init kprobes in early_initcall")
    Suggested-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Link: https://lore.kernel.org/r/20201103134900.337243-1-jean-philippe@linaro.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm: use fallback for random_get_entropy() instead of zero [+ + +]
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>

 
ASoC: cs35l36: Update digital volume TLV [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Jun 2 17:21:15 2022 +0100

    ASoC: cs35l36: Update digital volume TLV
    
    [ Upstream commit 5005a2345825eb8346546d99bfe669f73111b5c5 ]
    
    The digital volume TLV specifies the step as 0.25dB but the actual step
    of the control is 0.125dB. Update the TLV to correct this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220602162119.3393857-3-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs42l52: Correct TLV for Bypass Volume [+ + +]
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>

ASoC: cs42l52: Fix TLV scales for mixer controls [+ + +]
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>

ASoC: cs42l56: Correct typo in minimum level for SX volume controls [+ + +]
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>

ASoC: cs53l30: Correct number of volume levels on SX controls [+ + +]
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>

ASoC: es8328: Fix event generation for deemphasis control [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jun 3 14:39:37 2022 +0200

    ASoC: es8328: Fix event generation for deemphasis control
    
    [ Upstream commit 8259610c2ec01c5cbfb61882ae176aabacac9c19 ]
    
    Currently the put() method for the deemphasis control returns 0 when a new
    value is written to the control even if the value changed, meaning events
    are not generated. Fix this, skip the work of updating the value when it is
    unchanged and then return 1 after having done so.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20220603123937.4013603-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: nau8822: Add operation for internal PLL off and on [+ + +]
Author: Hui Wang <hui.wang@canonical.com>
Date:   Mon May 30 12:01:50 2022 +0800

    ASoC: nau8822: Add operation for internal PLL off and on
    
    [ Upstream commit aeca8a3295022bcec46697f16e098140423d8463 ]
    
    We tried to enable the audio on an imx6sx EVB with the codec nau8822,
    after setting the internal PLL fractional parameters, the audio still
    couldn't work and the there was no sdma irq at all.
    
    After checking with the section "8.1.1 Phase Locked Loop (PLL) Design
    Example" of "NAU88C22 Datasheet Rev 0.6", we found we need to
    turn off the PLL before programming fractional parameters and turn on
    the PLL after programming.
    
    After this change, the audio driver could record and play sound and
    the sdma's irq is triggered when playing or recording.
    
    Cc: David Lin <ctlin0@nuvoton.com>
    Cc: John Hsu <kchsu0@nuvoton.com>
    Cc: Seven Li <wtli@nuvoton.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20220530040151.95221-2-hui.wang@canonical.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm8962: Fix suspend while playing music [+ + +]
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>

ASoC: wm_adsp: Fix event generation for wm_adsp_fw_put() [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jun 3 13:50:03 2022 +0200

    ASoC: wm_adsp: Fix event generation for wm_adsp_fw_put()
    
    [ Upstream commit 2abdf9f80019e8244d3806ed0e1c9f725e50b452 ]
    
    Currently wm_adsp_fw_put() returns 0 rather than 1 when updating the value
    of the control, meaning that no event is generated to userspace. Fix this
    by setting the default return value to 1, the code already exits early with
    a return value of 0 if the value is unchanged.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220603115003.3865834-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() [+ + +]
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>

 
bpf: Fix incorrect memory charge cost calculation in stack_map_alloc() [+ + +]
Author: Yuntao Wang <ytcoode@gmail.com>
Date:   Tue Jun 14 22:26:22 2022 +0800

    bpf: Fix incorrect memory charge cost calculation in stack_map_alloc()
    
    commit b45043192b3e481304062938a6561da2ceea46a6 upstream.
    
    This is a backport of the original upstream patch for 5.4/5.10.
    
    The original upstream patch has been applied to 5.4/5.10 branches, which
    simply removed the line:
    
      cost += n_buckets * (value_size + sizeof(struct stack_map_bucket));
    
    This is correct for upstream branch but incorrect for 5.4/5.10 branches,
    as the 5.4/5.10 branches do not have the commit 370868107bf6 ("bpf:
    Eliminate rlimit-based memory accounting for stackmap maps"), so the
    bpf_map_charge_init() function has not been removed.
    
    Currently the bpf_map_charge_init() function in 5.4/5.10 branches takes a
    wrong memory charge cost, the
    
      attr->max_entries * (sizeof(struct stack_map_bucket) + (u64)value_size))
    
    part is missing, let's fix it.
    
    Cc: <stable@vger.kernel.org> # 5.4.y
    Cc: <stable@vger.kernel.org> # 5.10.y
    Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
certs/blacklist_hashes.c: fix const confusion in certs blacklist [+ + +]
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>

 
clocksource: hyper-v: unexport __init-annotated hv_init_clocksource() [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 14:02:38 2022 +0900

    clocksource: hyper-v: unexport __init-annotated hv_init_clocksource()
    
    [ Upstream commit 245b993d8f6c4e25f19191edfbd8080b645e12b1 ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the only in-tree call-site,
    arch/x86/kernel/cpu/mshyperv.c is never compiled as modular.
    (CONFIG_HYPERVISOR_GUEST is boolean)
    
    Fixes: dd2cb348613b ("clocksource/drivers: Continue making Hyper-V clocksource ISA agnostic")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Link: https://lore.kernel.org/r/20220606050238.4162200-1-masahiroy@kernel.org
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
comedi: vmk80xx: fix expression for tx buffer size [+ + +]
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>

 
compat_ioctl: remove /dev/random commands [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Sep 7 11:10:23 2018 +0200

    compat_ioctl: remove /dev/random commands
    
    commit 507e4e2b430b6a27b66f4745564ecaee7967737f upstream.
    
    These are all handled by the random driver, so instead of listing
    each ioctl, we can use the generic compat_ptr_ioctl() helper.
    
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
crypto: blake2s - adjust include guard naming [+ + +]
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>

crypto: blake2s - generic C library implementation and selftest [+ + +]
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>

crypto: blake2s - include instead of [+ + +]
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>

crypto: drbg - always seeded with SP800-90B compliant noise source [+ + +]
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>

crypto: drbg - always try to free Jitter RNG instance [+ + +]
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>

crypto: drbg - make reseeding from get_random_bytes() synchronous [+ + +]
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>

crypto: drbg - move dynamic ->reseed_threshold adjustments to __drbg_seed() [+ + +]
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>

crypto: drbg - prepare for more fine-grained tracking of seeding state [+ + +]
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>

crypto: drbg - track whether DRBG was seeded with !rng_is_initialized() [+ + +]
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>

 
dm mirror log: round up region bitmap size to BITS_PER_LONG [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jun 16 13:28:57 2022 -0400

    dm mirror log: round up region bitmap size to BITS_PER_LONG
    
    commit 85e123c27d5cbc22cfdc01de1e2ca1d9003a02d0 upstream.
    
    The code in dm-log rounds up bitset_size to 32 bits. It then uses
    find_next_zero_bit_le on the allocated region. find_next_zero_bit_le
    accesses the bitmap using unsigned long pointers. So, on 64-bit
    architectures, it may access 4 bytes beyond the allocated size.
    
    Fix this bug by rounding up bitset_size to BITS_PER_LONG.
    
    This bug was found by running the lvm2 testsuite with kasan.
    
    Fixes: 29121bd0b00e ("[PATCH] dm mirror log: bitset_size fix")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dma-debug: make things less spammy under memory pressure [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Wed Jun 1 07:51:16 2022 -0700

    dma-debug: make things less spammy under memory pressure
    
    [ Upstream commit e19f8fa6ce1ca9b8b934ba7d2e8f34c95abc6e60 ]
    
    Limit the error msg to avoid flooding the console.  If you have a lot of
    threads hitting this at once, they could have already gotten passed the
    dma_debug_disabled() check before they get to the point of allocation
    failure, resulting in quite a lot of this error message spamming the
    log.  Use pr_err_once() to limit that.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: add reserved GDT blocks check [+ + +]
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>

ext4: fix bug_on ext4_mb_use_inode_pa [+ + +]
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>

ext4: make variable "count" signed [+ + +]
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>

 
faddr2line: Fix overlapping text section failures, the sequel [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Jun 1 17:42:22 2022 -0700

    faddr2line: Fix overlapping text section failures, the sequel
    
    [ Upstream commit dcea997beed694cbd8705100ca1a6eb0d886de69 ]
    
    If a function lives in a section other than .text, but .text also exists
    in the object, faddr2line may wrongly assume .text.  This can result in
    comically wrong output.  For example:
    
      $ scripts/faddr2line vmlinux.o enter_from_user_mode+0x1c
      enter_from_user_mode+0x1c/0x30:
      find_next_bit at /home/jpoimboe/git/linux/./include/linux/find.h:40
      (inlined by) perf_clear_dirty_counters at /home/jpoimboe/git/linux/arch/x86/events/core.c:2504
    
    Fix it by passing the section name to addr2line, unless the object file
    is vmlinux, in which case the symbol table uses absolute addresses.
    
    Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures")
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Link: https://lore.kernel.org/r/7d25bc1408bd3a750ac26e60d2f2815a5f4a8363.1654130536.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: designware: Use standard optional ref clock implementation [+ + +]
Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Date:   Fri Jun 10 10:42:33 2022 +0300

    i2c: designware: Use standard optional ref clock implementation
    
    [ Upstream commit 27071b5cbca59d8e8f8750c199a6cbf8c9799963 ]
    
    Even though the DW I2C controller reference clock source is requested by
    the method devm_clk_get() with non-optional clock requirement the way the
    clock handler is used afterwards has a pure optional clock semantic
    (though in some circumstances we can get a warning about the clock missing
    printed in the system console). There is no point in reimplementing that
    functionality seeing the kernel clock framework already supports the
    optional interface from scratch. Thus let's convert the platform driver to
    using it.
    
    Note by providing this commit we get to fix two problems. The first one
    was introduced in commit c62ebb3d5f0d ("i2c: designware: Add support for
    an interface clock"). It causes not having the interface clock (pclk)
    enabled/disabled in case if the reference clock isn't provided. The second
    problem was first introduced in commit b33af11de236 ("i2c: designware: Do
    not require clock when SSCN and FFCN are provided"). Since that
    modification the deferred probe procedure has been unsupported in case if
    the interface clock isn't ready.
    
    Fixes: c62ebb3d5f0d ("i2c: designware: Add support for an interface clock")
    Fixes: b33af11de236 ("i2c: designware: Do not require clock when SSCN and FFCN are provided")
    Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Fix adding ADQ filter to TC0 [+ + +]
Author: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
Date:   Fri Apr 29 14:27:08 2022 +0200

    i40e: Fix adding ADQ filter to TC0
    
    [ Upstream commit c3238d36c3a2be0a29a9d848d6c51e1b14be6692 ]
    
    Procedure of configure tc flower filters erroneously allows to create
    filters on TC0 where unfiltered packets are also directed by default.
    Issue was caused by insufficient checks of hw_tc parameter specifying
    the hardware traffic class to pass matching packets to.
    
    Fix checking hw_tc parameter which blocks creation of filters on TC0.
    
    Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Fix calculating the number of queue pairs [+ + +]
Author: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
Date:   Fri Apr 29 14:40:23 2022 +0200

    i40e: Fix calculating the number of queue pairs
    
    [ Upstream commit 0bb050670ac90a167ecfa3f9590f92966c9a3677 ]
    
    If ADQ is enabled for a VF, then actual number of queue pair
    is a number of currently available traffic classes for this VF.
    
    Without this change the configuration of the Rx/Tx queues
    fails with error.
    
    Fixes: d29e0d233e0d ("i40e: missing input validation on VF message handling by the PF")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Fix call trace in setup_tx_descriptors [+ + +]
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>

 
ia64: define get_cycles macro for arch-override [+ + +]
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>

 
init: call time_init() before rand_initialize() [+ + +]
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>

 
ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg [+ + +]
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>

 
irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:28 2022 +0400

    irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions
    
    [ Upstream commit ec8401a429ffee34ccf38cebf3443f8d5ae6cb0d ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    When kcalloc fails, it missing of_node_put() and results in refcount
    leak. Fix this by goto out_put_node label.
    
    Fixes: 52085d3f2028 ("irqchip/gic-v3: Dynamically allocate PPI partition descriptors")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-5-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:09:29 2022 +0400

    irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions
    
    [ Upstream commit fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b ]
    
    of_find_node_by_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.
    
    Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220601080930.31005-6-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic/realview: Fix refcount leak in realview_gic_of_init [+ + +]
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>

 
lib/crypto: blake2s: move hmac construction into wireguard [+ + +]
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>

lib/crypto: sha1: re-roll loops to reduce code size [+ + +]
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>

 
Linux: Linux 5.4.200 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 22 14:11:24 2022 +0200

    Linux 5.4.200
    
    Link: https://lore.kernel.org/r/20220620124737.799371052@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
linux/random.h: Mark CONFIG_ARCH_RANDOM functions __must_check [+ + +]
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>

linux/random.h: Remove arch_has_random, arch_has_random_seed [+ + +]
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>

linux/random.h: Use false with bool [+ + +]
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>

 
m68k: use fallback for random_get_entropy() instead of zero [+ + +]
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>

 
MAINTAINERS: co-maintain random.c [+ + +]
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>

 
mips: use fallback for random_get_entropy() instead of just c0 random [+ + +]
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>

 
misc: atmel-ssc: Fix IRQ check in ssc_probe [+ + +]
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>

 
mlxsw: spectrum_cnt: Reorder counter pools [+ + +]
Author: Petr Machata <petrm@nvidia.com>
Date:   Mon Jun 13 15:50:17 2022 +0300

    mlxsw: spectrum_cnt: Reorder counter pools
    
    [ Upstream commit 4b7a632ac4e7101ceefee8484d5c2ca505d347b3 ]
    
    Both RIF and ACL flow counters use a 24-bit SW-managed counter address to
    communicate which counter they want to bind.
    
    In a number of Spectrum FW releases, binding a RIF counter is broken and
    slices the counter index to 16 bits. As a result, on Spectrum-2 and above,
    no more than about 410 RIF counters can be effectively used. This
    translates to 205 netdevices for which L3 HW stats can be enabled. (This
    does not happen on Spectrum-1, because there are fewer counters available
    overall and the counter index never exceeds 16 bits.)
    
    Binding counters to ACLs does not have this issue. Therefore reorder the
    counter allocation scheme so that RIF counters come first and therefore get
    lower indices that are below the 16-bit barrier.
    
    Fixes: 98e60dce4da1 ("Merge branch 'mlxsw-Introduce-initial-Spectrum-2-support'")
    Reported-by: Maksym Yaremchuk <maksymy@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://lore.kernel.org/r/20220613125017.2018162-1-idosch@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_police: more accurate MTU policing [+ + +]
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Thu Feb 10 18:56:08 2022 +0100

    net/sched: act_police: more accurate MTU policing
    
    commit 4ddc844eb81da59bfb816d8d52089aba4e59e269 upstream.
    
    in current Linux, MTU policing does not take into account that packets at
    the TC ingress have the L2 header pulled. Thus, the same TC police action
    (with the same value of tcfp_mtu) behaves differently for ingress/egress.
    In addition, the full GSO size is compared to tcfp_mtu: as a consequence,
    the policer drops GSO packets even when individual segments have the L2 +
    L3 + L4 + payload length below the configured valued of tcfp_mtu.
    
    Improve the accuracy of MTU policing as follows:
     - account for mac_len for non-GSO packets at TC ingress.
     - compare MTU threshold with the segmented size for GSO packets.
    Also, add a kselftest that verifies the correct behavior.
    
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [dcaratti: fix conflicts due to lack of the following commits:
     - commit 2ffe0395288a ("net/sched: act_police: add support for
       packet-per-second policing")
     - commit afe231d32eb5 ("selftests: forwarding: Add tc-police tests")
     - commit 53b61f29367d ("selftests: forwarding: Add tc-police tests for
       packets per second")]
    Link: https://lore.kernel.org/netdev/876d597a0ff55f6ba786f73c5a9fd9eb8d597a03.1644514748.git.dcaratti@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: bgmac: Fix an erroneous kfree() in bgmac_remove() [+ + +]
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>

net: ethernet: mtk_eth_soc: fix misuse of mem alloc interface netdev[napi]_alloc_frag [+ + +]
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>

net: openvswitch: fix leak of nested actions [+ + +]
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Mon Apr 4 17:43:45 2022 +0200

    net: openvswitch: fix leak of nested actions
    
    commit 1f30fb9166d4f15a1aa19449b9da871fe0ed4796 upstream.
    
    While parsing user-provided actions, openvswitch module may dynamically
    allocate memory and store pointers in the internal copy of the actions.
    So this memory has to be freed while destroying the actions.
    
    Currently there are only two such actions: ct() and set().  However,
    there are many actions that can hold nested lists of actions and
    ovs_nla_free_flow_actions() just jumps over them leaking the memory.
    
    For example, removal of the flow with the following actions will lead
    to a leak of the memory allocated by nf_ct_tmpl_alloc():
    
      actions:clone(ct(commit),0)
    
    Non-freed set() action may also leak the 'dst' structure for the
    tunnel info including device references.
    
    Under certain conditions with a high rate of flow rotation that may
    cause significant memory leak problem (2MB per second in reporter's
    case).  The problem is also hard to mitigate, because the user doesn't
    have direct control over the datapath flows generated by OVS.
    
    Fix that by iterating over all the nested actions and freeing
    everything that needs to be freed recursively.
    
    New build time assertion should protect us from this problem if new
    actions will be added in the future.
    
    Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all
    attributes has to be explicitly checked.  sample() and clone() actions
    are mixing extra attributes into the user-provided action list.  That
    prevents some code generalization too.
    
    Fixes: 34ae932a4036 ("openvswitch: Make tunnel set action attach a metadata dst")
    Link: https://mail.openvswitch.org/pipermail/ovs-dev/2022-March/392922.html
    Reported-by: Stéphane Graber <stgraber@ubuntu.com>
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Acked-by: Aaron Conole <aconole@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [Backport for 5.4: Removed handling of OVS_ACTION_ATTR_DEC_TTL as it
     doesn't exist in this version.  BUILD_BUG_ON condition adjusted
     accordingly.]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: openvswitch: fix misuse of the cached connection on tuple changes [+ + +]
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Tue Jun 7 00:11:40 2022 +0200

    net: openvswitch: fix misuse of the cached connection on tuple changes
    
    commit 2061ecfdf2350994e5b61c43e50e98a7a70e95ee upstream.
    
    If packet headers changed, the cached nfct is no longer relevant
    for the packet and attempt to re-use it leads to the incorrect packet
    classification.
    
    This issue is causing broken connectivity in OpenStack deployments
    with OVS/OVN due to hairpin traffic being unexpectedly dropped.
    
    The setup has datapath flows with several conntrack actions and tuple
    changes between them:
    
      actions:ct(commit,zone=8,mark=0/0x1,nat(src)),
              set(eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:06)),
              set(ipv4(src=172.18.2.10,dst=192.168.100.6,ttl=62)),
              ct(zone=8),recirc(0x4)
    
    After the first ct() action the packet headers are almost fully
    re-written.  The next ct() tries to re-use the existing nfct entry
    and marks the packet as invalid, so it gets dropped later in the
    pipeline.
    
    Clearing the cached conntrack entry whenever packet tuple is changed
    to avoid the issue.
    
    The flow key should not be cleared though, because we should still
    be able to match on the ct_state if the recirculation happens after
    the tuple change but before the next ct() action.
    
    Cc: stable@vger.kernel.org
    Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
    Reported-by: Frode Nordahl <frode.nordahl@canonical.com>
    Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051829.html
    Link: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/1967856
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Link: https://lore.kernel.org/r/20220606221140.488984-1-i.maximets@ovn.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [Backport to 5.10: minor rebase in ovs_ct_clear function.
     This version also applicable to and tested on 5.4 and 4.19.]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred [+ + +]
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>

nfc: st21nfca: fix incorrect sizing calculations in EVT_TRANSACTION [+ + +]
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:29 2022 -0500

    nfc: st21nfca: fix incorrect sizing calculations in EVT_TRANSACTION
    
    commit f2e19b36593caed4c977c2f55aeba7408aeb2132 upstream.
    
    The transaction buffer is allocated by using the size of the packet buf,
    and subtracting two which seem intended to remove the two tags which are
    not present in the target structure. This calculation leads to under
    counting memory because of differences between the packet contents and the
    target structure. The aid_len field is a u8 in the packet, but a u32 in
    the structure, resulting in at least 3 bytes always being under counted.
    Further, the aid data is a variable length field in the packet, but fixed
    in the structure, so if this field is less than the max, the difference is
    added to the under counting.
    
    The last validation check for transaction->params_len is also incorrect
    since it employs the same accounting error.
    
    To fix, perform validation checks progressively to safely reach the
    next field, to determine the size of both buffers and verify both tags.
    Once all validation checks pass, allocate the buffer and copy the data.
    This eliminates freeing memory on the error path, as those checks are
    moved ahead of memory allocation.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nios2: use fallback for random_get_entropy() instead of zero [+ + +]
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>

 
parisc: define get_cycles macro for arch-override [+ + +]
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>

 
pNFS: Don't keep retrying if the server replied NFS4ERR_LAYOUTUNAVAILABLE [+ + +]
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>

 
powerpc/kasan: Silence KASAN warnings in __get_wchan() [+ + +]
Author: He Ying <heying24@huawei.com>
Date:   Thu Jan 20 20:44:18 2022 -0500

    powerpc/kasan: Silence KASAN warnings in __get_wchan()
    
    [ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
    
    The following KASAN warning was reported in our kernel.
    
      BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
      Read of size 4 at addr d216f958 by task ps/14437
    
      CPU: 3 PID: 14437 Comm: ps Tainted: G           O      5.10.0 #1
      Call Trace:
      [daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
      [daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
      [daa63908] [c035d6bc] kasan_report+0x1ac/0x218
      [daa63948] [c00496e8] get_wchan+0x188/0x250
      [daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
      [daa63b98] [c0455ac8] proc_single_show+0x98/0x170
      [daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
      [daa63c38] [c03cb47c] seq_read+0x1dc/0x290
      [daa63d68] [c037fc94] vfs_read+0x164/0x510
      [daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
      [daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
      --- interrupt: c00 at 0x8fa8f4
          LR = 0x8fa8cc
    
      The buggy address belongs to the page:
      page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
      flags: 0x0()
      raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
      raw: 00000000
      page dumped because: kasan: bad access detected
    
      Memory state around the buggy address:
       d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
       d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
                                                ^
       d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
       d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    After looking into this issue, I find the buggy address belongs
    to the task stack region. It seems KASAN has something wrong.
    I look into the code of __get_wchan in x86 architecture and
    find the same issue has been resolved by the commit
    f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
    The solution could be applied to powerpc architecture too.
    
    As Andrey Ryabinin said, get_wchan() is racy by design, it may
    access volatile stack of running task, thus it may access
    redzone in a stack frame and cause KASAN to warn about this.
    
    Use READ_ONCE_NOCHECK() to silence these warnings.
    
    Reported-by: Wanming Hu <huwanming@huaweil.com>
    Signed-off-by: He Ying <heying24@huawei.com>
    Signed-off-by: Chen Jingwen <chenjingwen6@huawei.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/mm: Switch obsolete dssall to .long [+ + +]
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Tue Dec 21 16:59:03 2021 +1100

    powerpc/mm: Switch obsolete dssall to .long
    
    commit d51f86cfd8e378d4907958db77da3074f6dce3ba upstream.
    
    The dssall ("Data Stream Stop All") instruction is obsolete altogether
    with other Data Cache Instructions since ISA 2.03 (year 2006).
    
    LLVM IAS does not support it but PPC970 seems to be using it.
    This switches dssall to .long as there is no much point in fixing LLVM.
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211221055904.555763-6-aik@ozlabs.ru
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc: define get_cycles macro for arch-override [+ + +]
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>

powerpc: Remove arch_has_random, arch_has_random_seed [+ + +]
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>

powerpc: Use bool in archrandom.h [+ + +]
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>

 
random: absorb fast pool into input pool after fast load [+ + +]
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>

random: access input_pool_data directly rather than through pointer [+ + +]
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>

random: access primary_pool directly rather than through pointer [+ + +]
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>

random: account for arch randomness in bits [+ + +]
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>

random: Add a urandom_read_nowait() for random APIs that don't warn [+ + +]
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>

random: Add and use pr_fmt() [+ + +]
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>

random: add arch_get_random_*long_early() [+ + +]
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>

random: add GRND_INSECURE to return best-effort non-cryptographic bytes [+ + +]
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>

random: add proper SPDX header [+ + +]
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>

random: allow partial reads if later user copies fail [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Apr 7 21:23:08 2022 +0200

    random: allow partial reads if later user copies fail
    
    commit 5209aed5137880fa229746cb521f715e55596460 upstream.
    
    Rather than failing entirely if a copy_to_user() fails at some point,
    instead we should return a partial read for the amount that succeeded
    prior, unless none succeeded at all, in which case we return -EFAULT as
    before.
    
    This makes it consistent with other reader interfaces. For example, the
    following snippet for /dev/zero outputs "4" followed by "1":
    
      int fd;
      void *x = mmap(NULL, 4096, PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
      assert(x != MAP_FAILED);
      fd = open("/dev/zero", O_RDONLY);
      assert(fd >= 0);
      printf("%zd\n", read(fd, x, 4));
      printf("%zd\n", read(fd, x + 4095, 4));
      close(fd);
    
    This brings that same standard behavior to the various RNG reader
    interfaces.
    
    While we're at it, we can streamline the loop logic a little bit.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jann Horn <jannh@google.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

random: always wake up entropy writers after extraction [+ + +]
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>

random: avoid arch_get_random_seed_long() when collecting IRQ randomness [+ + +]
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>

random: avoid checking crng_ready() twice in random_init() [+ + +]
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>

random: avoid initializing twice in credit race [+ + +]
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>

random: avoid superfluous call to RDRAND in CRNG extraction [+ + +]
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>

random: avoid warnings for !CONFIG_NUMA builds [+ + +]
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>

random: check for crng_init == 0 in add_device_randomness() [+ + +]
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>

random: check for signal and try earlier when generating entropy [+ + +]
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>

random: check for signal_pending() outside of need_resched() check [+ + +]
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>

random: check for signals after page of pool writes [+ + +]
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>

random: check for signals every PAGE_SIZE chunk of /dev/[u]random [+ + +]
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>

random: cleanup fractional entropy shift constants [+ + +]
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>

random: cleanup integer types [+ + +]
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>

random: cleanup poolinfo abstraction [+ + +]
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>

random: cleanup UUID handling [+ + +]
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>

random: clear fast pool, crng, and batches in cpuhp bring up [+ + +]
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>

random: continually use hwgenerator randomness [+ + +]
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>

random: convert to ENTROPY_BITS for better code readability [+ + +]
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>

random: convert to using fops->read_iter() [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu May 19 17:31:36 2022 -0600

    random: convert to using fops->read_iter()
    
    commit 1b388e7765f2eaa137cf5d92b47ef5925ad83ced upstream.
    
    This is a pre-requisite to wiring up splice() again for the random
    and urandom drivers. It also allows us to remove the INT_MAX check in
    getrandom(), because import_single_range() applies capping internally.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [Jason: rewrote get_random_bytes_user() to simplify and also incorporate
     additional 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>

random: convert to using fops->write_iter() [+ + +]
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>

random: credit architectural init the exact amount [+ + +]
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>

random: credit cpu and bootloader seeds by default [+ + +]
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>

random: de-duplicate INPUT_POOL constants [+ + +]
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>

random: defer fast pool mixing to worker [+ + +]
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>

random: delete code to pull data into pools [+ + +]
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>

random: deobfuscate irq u32/u64 contributions [+ + +]
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>

random: do crng pre-init loading in worker rather than irq [+ + +]
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>

random: do not allow user to keep crng key around on stack [+ + +]
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>

random: do not pretend to handle premature next security model [+ + +]
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>

random: do not re-init if crng_reseed completes before primary init [+ + +]
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>

random: do not sign extend bytes for rotation when mixing [+ + +]
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>

random: do not split fast init input in add_hwgenerator_randomness() [+ + +]
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>

random: do not take pool spinlock at boot [+ + +]
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>

random: do not use batches when !crng_ready() [+ + +]
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>

random: do not use input pool from hard IRQs [+ + +]
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>

random: do not xor RDRAND when writing into /dev/random [+ + +]
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>

random: document add_hwgenerator_randomness() with other input functions [+ + +]
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>

random: document crng_fast_key_erasure() destination possibility [+ + +]
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>

random: don't forget compat_ioctl on urandom [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Dec 17 18:24:55 2019 +0100

    random: don't forget compat_ioctl on urandom
    
    commit 4aa37c463764052c68c5c430af2a67b5d784c1e0 upstream.
    
    Recently, there's been some compat ioctl cleanup, in which large
    hardcoded lists were replaced with compat_ptr_ioctl. One of these
    changes involved removing the random.c hardcoded list entries and adding
    a compat ioctl function pointer to the random.c fops. In the process,
    urandom was forgotten about, so this commit fixes that oversight.
    
    Fixes: 507e4e2b430b ("compat_ioctl: remove /dev/random commands")
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://lore.kernel.org/r/20191217172455.186395-1-Jason@zx2c4.com
    Signed-off-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>

random: don't let 644 read-only sysctls be written to [+ + +]
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>

random: don't reset crng_init_cnt on urandom_read() [+ + +]
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>

random: Don't wake crng_init_wait when crng_init == 1 [+ + +]
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>

random: early initialization of ChaCha constants [+ + +]
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>

random: ensure early RDSEED goes through mixer on init [+ + +]
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>

random: fix locking for crng_init in crng_reseed() [+ + +]
Author: Dominik Brodowski <linux@dominikbrodowski.net>
Date:   Wed Feb 9 19:57:06 2022 +0100

    random: fix locking for crng_init in crng_reseed()
    
    commit 7191c628fe07b70d3f37de736d173d1b115396ed upstream.
    
    crng_init is protected by primary_crng->lock. Therefore, we need
    to hold this lock when increasing crng_init to 2. As we shouldn't
    hold this lock for too long, only hold it for those parts which
    require protection.
    
    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>

random: fix locking in crng_fast_load() [+ + +]
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>

random: fix sysctl documentation nits [+ + +]
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>

random: fix typo in add_timer_randomness() [+ + +]
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>

random: fix typo in comments [+ + +]
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>

random: get rid of secondary crngs [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun Feb 6 23:51:41 2022 +0100

    random: get rid of secondary crngs
    
    commit a9412d510ab9a9ba411fea612903631d2e1f1601 upstream.
    
    As the comment said, this is indeed a "hack". Since it was introduced,
    it's been a constant state machine nightmare, with lots of subtle early
    boot issues and a wildly complex set of machinery to keep everything in
    sync. Rather than continuing to play whack-a-mole with this approach,
    this commit simply removes it entirely. This commit is preparation for
    "random: use simpler fast key erasure flow on per-cpu keys" in this
    series, which introduces a simpler (and faster) mechanism to accomplish
    the same thing.
    
    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>

random: give sysctl_random_min_urandom_seed a more sensible value [+ + +]
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>

random: group crng functions [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Feb 11 12:53:34 2022 +0100

    random: group crng functions
    
    commit 3655adc7089da4f8ca74cec8fcef73ea5101430e upstream.
    
    This pulls all of the crng-focused functions into the second 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>

random: group entropy collection functions [+ + +]
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>

random: group entropy extraction functions [+ + +]
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>

random: group initialization wait functions [+ + +]
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>

random: group sysctl functions [+ + +]
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>

random: group userspace read/write functions [+ + +]
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>

random: handle latent entropy and command line from random_init() [+ + +]
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>

random: harmonize "crng init done" messages [+ + +]
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>

random: help compiler out with fast_mix() by using simpler arguments [+ + +]
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>

random: ignore GRND_RANDOM in getentropy(2) [+ + +]
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>

random: initialize ChaCha20 constants with correct endianness [+ + +]
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>

random: inline leaves of rand_initialize() [+ + +]
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>

random: insist on random_get_entropy() existing in order to simplify [+ + +]
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>

random: introduce drain_entropy() helper to declutter crng_reseed() [+ + +]
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>

random: make /dev/random be almost like /dev/urandom [+ + +]
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>

random: make consistent usage of crng_ready() [+ + +]
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>

random: make consistent use of buf and len [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri May 13 13:18:46 2022 +0200

    random: make consistent use of buf and len
    
    commit a19402634c435a4eae226df53c141cdbb9922e7b upstream.
    
    The current code was a mix of "nbytes", "count", "size", "buffer", "in",
    and so forth. Instead, let's clean this up by naming input parameters
    "buf" (or "ubuf") and "len", so that you always understand that you're
    reading this variety of function argument.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

random: make credit_entropy_bits() always safe [+ + +]
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>

random: make more consistent use of integer types [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Feb 9 14:43:25 2022 +0100

    random: make more consistent use of integer types
    
    commit 04ec96b768c9dd43946b047c3da60dcc66431370 upstream.
    
    We've been using a flurry of int, unsigned int, size_t, and ssize_t.
    Let's unify all of this into size_t where it makes sense, as it does in
    most places, and leave ssize_t for return values with possible errors.
    
    In addition, keeping with the convention of other functions in this
    file, functions that are dealing with raw bytes now take void *
    consistently instead of a mix of that and u8 *, because much of the time
    we're actually passing some other structure that is then interpreted as
    bytes by the function.
    
    We also take the opportunity to fix the outdated and incorrect comment
    in get_random_bytes_arch().
    
    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>

random: make random_get_entropy() return an unsigned long [+ + +]
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>

random: mark bootloader randomness code as __init [+ + +]
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>

random: mix bootloader randomness into pool [+ + +]
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>

random: mix build-time latent entropy into pool at init [+ + +]
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>

random: move initialization functions out of hot pages [+ + +]
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>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

random: move initialization out of reseeding hot path [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon May 9 13:53:24 2022 +0200

    random: move initialization out of reseeding hot path
    
    commit 68c9c8b192c6dae9be6278e98ee44029d5da2d31 upstream.
    
    Initialization happens once -- by way of credit_init_bits() -- and then
    it never happens again. Therefore, it doesn't need to be in
    crng_reseed(), which is a hot path that is called multiple times. It
    also doesn't make sense to have there, as initialization activity is
    better associated with initialization routines.
    
    After the prior commit, crng_reseed() now won't be called by multiple
    concurrent callers, which means that we can safely move the
    "finialize_init" logic into crng_init_bits() unconditionally.
    
    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>

random: move randomize_page() into mm where it belongs [+ + +]
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>

random: only call crng_finalize_init() for primary_crng [+ + +]
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>

random: only wake up writers after zap if threshold was passed [+ + +]
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>

random: order timer entropy functions below interrupt functions [+ + +]
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>

random: prepend remaining pool constants with POOL_ [+ + +]
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>

random: pull add_hwgenerator_randomness() declaration into random.h [+ + +]
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>

random: rather than entropy_store abstraction, use global [+ + +]
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>

random: re-add removed comment about get_random_{u32,u64} reseeding [+ + +]
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>

random: remove batched entropy locking [+ + +]
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>

random: remove dead code left over from blocking pool [+ + +]
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>

random: remove extern from functions in header [+ + +]
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>

random: remove ifdef'd out interrupt bench [+ + +]
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>

random: remove incomplete last_data logic [+ + +]
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>

random: remove kernel.random.read_wakeup_threshold [+ + +]
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>

random: remove outdated INT_MAX >> 6 check in urandom_read() [+ + +]
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>

random: remove ratelimiting for in-kernel unseeded randomness [+ + +]
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>

random: remove some dead code of poolinfo [+ + +]
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>

random: remove the blocking pool [+ + +]
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>

random: remove unnecessary unlikely() [+ + +]
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>

random: remove unused extract_entropy() reserved argument [+ + +]
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>

random: remove unused irq_flags argument from add_interrupt_randomness() [+ + +]
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>

random: remove unused OUTPUT_POOL constants [+ + +]
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>

random: remove unused tracepoints [+ + +]
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>

random: remove use_input_pool parameter from crng_reseed() [+ + +]
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>

random: remove useless header comment [+ + +]
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>

random: remove whitespace and reorder includes [+ + +]
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>

random: replace custom notifier chain with standard one [+ + +]
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>

random: reseed more often immediately after booting [+ + +]
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>

random: rewrite header introductory comment [+ + +]
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>

random: round-robin registers as ulong, not u32 [+ + +]
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>

random: selectively clang-format where it makes sense [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Jan 15 14:57:22 2022 +0100

    random: selectively clang-format where it makes sense
    
    commit 248045b8dea5a32ddc0aa44193d6bc70c4b9cd8e upstream.
    
    This is an old driver that has seen a lot of different eras of kernel
    coding style. In an effort to make it easier to code for, unify the
    coding style around the current norm, by accepting some of -- but
    certainly not all of -- the suggestions from clang-format. This should
    remove ambiguity in coding style, especially with regards to spacing,
    when code is being changed or amended. Consequently it also makes code
    review easier on the eyes, following one uniform style rather than
    several.
    
    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>

random: simplify arithmetic function flow in account() [+ + +]
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>

random: simplify entropy debiting [+ + +]
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>

random: skip fast_init if hwrng provides large chunk of entropy [+ + +]
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>

random: split primary/secondary crng init paths [+ + +]
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>

random: tie batched entropy generation to base_crng generation [+ + +]
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>

random: treat bootloader trust toggle the same way as cpu trust toggle [+ + +]
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>

random: unify batched entropy implementations [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sun May 15 00:22:05 2022 +0200

    random: unify batched entropy implementations
    
    commit 3092adcef3ffd2ef59634998297ca8358461ebce upstream.
    
    There are currently two separate batched entropy implementations, for
    u32 and u64, with nearly identical code, with the goal of avoiding
    unaligned memory accesses and letting the buffers be used more
    efficiently. Having to maintain these two functions independently is a
    bit of a hassle though, considering that they always need to be kept in
    sync.
    
    This commit factors them out into a type-generic macro, so that the
    expansion produces the same code as before, such that diffing the
    assembly shows no differences. This will also make it easier in the
    future to add u16 and u8 batches.
    
    This was initially tested using an always_inline function and letting
    gcc constant fold the type size in, but the code gen was less efficient,
    and in general it was more verbose and harder to follow. So this patch
    goes with the boring macro solution, similar to what's already done for
    the _wait functions in random.h.
    
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

random: unify cycles_t and jiffies usage and types [+ + +]
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>

random: unify early init crng load accounting [+ + +]
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>

random: use BLAKE2s instead of SHA1 in extraction [+ + +]
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>

random: use computational hash for entropy extraction [+ + +]
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>

random: use first 128 bits of input as fast init [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Apr 30 15:08:20 2022 +0200

    random: use first 128 bits of input as fast init
    
    commit 5c3b747ef54fa2a7318776777f6044540d99f721 upstream.
    
    Before, the first 64 bytes of input, regardless of how entropic it was,
    would be used to mutate the crng base key directly, and none of those
    bytes would be credited as having entropy. Then 256 bits of credited
    input would be accumulated, and only then would the rng transition from
    the earlier "fast init" phase into being actually initialized.
    
    The thinking was that by mixing and matching fast init and real init, an
    attacker who compromised the fast init state, considered easy to do
    given how little entropy might be in those first 64 bytes, would then be
    able to bruteforce bits from the actual initialization. By keeping these
    separate, bruteforcing became impossible.
    
    However, by not crediting potentially creditable bits from those first 64
    bytes of input, we delay initialization, and actually make the problem
    worse, because it means the user is drawing worse random numbers for a
    longer period of time.
    
    Instead, we can take the first 128 bits as fast init, and allow them to
    be credited, and then hold off on the next 128 bits until they've
    accumulated. This is still a wide enough margin to prevent bruteforcing
    the rng state, while still initializing much faster.
    
    Then, rather than trying to piecemeal inject into the base crng key at
    various points, instead just extract from the pool when we need it, for
    the crng_init==0 phase. Performance may even be better for the various
    inputs here, since there are likely more calls to mix_pool_bytes() then
    there are to get_random_bytes() during this phase of system execution.
    
    Since the preinit injection code is gone, bootloader randomness can then
    do something significantly more straight forward, removing the weird
    system_wq hack in hwgenerator randomness.
    
    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>

random: use hash function for crng_slow_load() [+ + +]
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>

random: use IS_ENABLED(CONFIG_NUMA) instead of ifdefs [+ + +]
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>

random: use linear min-entropy accumulation crediting [+ + +]
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>

random: use proper jiffies comparison macro [+ + +]
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>

random: use proper return types on get_random_{int,long}_wait() [+ + +]
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>

random: use RDSEED instead of RDRAND in entropy extraction [+ + +]
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>

random: use simpler fast key erasure flow on per-cpu keys [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Feb 7 15:08:49 2022 +0100

    random: use simpler fast key erasure flow on per-cpu keys
    
    commit 186873c549df11b63e17062f863654e1501e1524 upstream.
    
    Rather than the clunky NUMA full ChaCha state system we had prior, this
    commit is closer to the original "fast key erasure RNG" proposal from
    <https://blog.cr.yp.to/20170723-random.html>, by simply treating ChaCha
    keys on a per-cpu basis.
    
    All entropy is extracted to a base crng key of 32 bytes. This base crng
    has a birthdate and a generation counter. When we go to take bytes from
    the crng, we first check if the birthdate is too old; if it is, we
    reseed per usual. Then we start working on a per-cpu crng.
    
    This per-cpu crng makes sure that it has the same generation counter as
    the base crng. If it doesn't, it does fast key erasure with the base
    crng key and uses the output as its new per-cpu key, and then updates
    its local generation counter. Then, using this per-cpu state, we do
    ordinary fast key erasure. Half of this first block is used to overwrite
    the per-cpu crng key for the next call -- this is the fast key erasure
    RNG idea -- and the other half, along with the ChaCha state, is returned
    to the caller. If the caller desires more than this remaining half, it
    can generate more ChaCha blocks, unlocked, using the now detached ChaCha
    state that was just returned. Crypto-wise, this is more or less what we
    were doing before, but this simply makes it more explicit and ensures
    that we always have backtrack protection by not playing games with a
    shared block counter.
    
    The flow looks like this:
    
    ──extract()──► base_crng.key ◄──memcpy()───┐
                       │                       │
                       └──chacha()──────┬─► new_base_key
                                        └─► crngs[n].key ◄──memcpy()───┐
                                                  │                    │
                                                  └──chacha()───┬─► new_key
                                                                └─► random_bytes
                                                                          │
                                                                          └────►
    
    There are a few hairy details around early init. Just as was done
    before, prior to having gathered enough entropy, crng_fast_load() and
    crng_slow_load() dump bytes directly into the base crng, and when we go
    to take bytes from the crng, in that case, we're doing fast key erasure
    with the base crng rather than the fast unlocked per-cpu crngs. This is
    fine as that's only the state of affairs during very early boot; once
    the crng initializes we never use these paths again.
    
    In the process of all this, the APIs into the crng become a bit simpler:
    we have get_random_bytes(buf, len) and get_random_bytes_user(buf, len),
    which both do what you'd expect. All of the details of fast key erasure
    and per-cpu selection happen only in a very short critical section of
    crng_make_state(), which selects the right per-cpu key, does the fast
    key erasure, and returns a local state to the caller's stack. So, we no
    longer have a need for a separate backtrack function, as this happens
    all at once here. The API then allows us to extend backtrack protection
    to batched entropy without really having to do much at all.
    
    The result is a bit simpler than before and has fewer foot guns. The
    init time state machine also gets a lot simpler as we don't need to wait
    for workqueues to come online and do deferred work. And the multi-core
    performance should be increased significantly, by virtue of having hardly
    any locking on the fast path.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    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>

random: use SipHash as interrupt entropy accumulator [+ + +]
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>

random: use static branch for crng_ready() [+ + +]
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>

random: use symbolic constants for crng_init states [+ + +]
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>

random: wire up fops->splice_{read,write}_iter() [+ + +]
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>

random: zero buffer after reading entropy from userspace [+ + +]
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>

 
Revert "random: use static branch for crng_ready()" [+ + +]
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>

 
RISC-V: fix barrier() use in [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Nov 16 17:39:51 2020 -0800

    RISC-V: fix barrier() use in <vdso/processor.h>
    
    commit 30aca1bacb398dec6c1ed5eeca33f355bd7b6203 upstream.
    
    riscv's <vdso/processor.h> uses barrier() so it should include
    <asm/barrier.h>
    
    Fixes this build error:
      CC [M]  drivers/net/ethernet/emulex/benet/be_main.o
    In file included from ./include/vdso/processor.h:10,
                     from ./arch/riscv/include/asm/processor.h:11,
                     from ./include/linux/prefetch.h:15,
                     from drivers/net/ethernet/emulex/benet/be_main.c:14:
    ./arch/riscv/include/asm/vdso/processor.h: In function 'cpu_relax':
    ./arch/riscv/include/asm/vdso/processor.h:14:2: error: implicit declaration of function 'barrier' [-Werror=implicit-function-declaration]
       14 |  barrier();
    
    This happens with a total of 5 networking drivers -- they all use
    <linux/prefetch.h>.
    
    rv64 allmodconfig now builds cleanly after this patch.
    
    Fixes fallout from:
    815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive")
    
    Fixes: ad5d1122b82f ("riscv: use vDSO common flow to reduce the latency of the time-related functions")
    Reported-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Arvind Sankar <nivedita@alum.mit.edu>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    [sudip: change in old path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: Less inefficient gcc tishift helpers (and export their symbols) [+ + +]
Author: Olof Johansson <olof@lixom.net>
Date:   Mon Dec 16 20:06:31 2019 -0800

    riscv: Less inefficient gcc tishift helpers (and export their symbols)
    
    commit fc585d4a5cf614727f64d86550b794bcad29d5c3 upstream.
    
    The existing __lshrti3 was really inefficient, and the other two helpers
    are also needed to compile some modules.
    
    Add the missing versions, and export all of the symbols like arm64
    already does.
    
    This code is based on the assembly generated by libgcc builds.
    
    This fixes a build break triggered by ubsan:
    
    riscv64-unknown-linux-gnu-ld: lib/ubsan.o: in function `.L2':
    ubsan.c:(.text.unlikely+0x38): undefined reference to `__ashlti3'
    riscv64-unknown-linux-gnu-ld: ubsan.c:(.text.unlikely+0x42): undefined reference to `__ashrti3'
    
    Signed-off-by: Olof Johansson <olof@lixom.net>
    [paul.walmsley@sifive.com: use SYM_FUNC_{START,END} instead of
     ENTRY/ENDPROC; note libgcc origin]
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390: define get_cycles macro for arch-override [+ + +]
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>

s390: Remove arch_has_random, arch_has_random_seed [+ + +]
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>

 
scsi: ipr: Fix missing/incorrect resource cleanup in error case [+ + +]
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>

scsi: lpfc: Allow reduced polling rate for nvme_admin_async_event cmd completion [+ + +]
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jun 3 10:43:28 2022 -0700

    scsi: lpfc: Allow reduced polling rate for nvme_admin_async_event cmd completion
    
    [ Upstream commit 2e7e9c0c1ec05f18d320ecc8a31eec59d2af1af9 ]
    
    NVMe Asynchronous Event Request commands have no command timeout value per
    specifications.
    
    Set WQE option to allow a reduced FLUSH polling rate for I/O error
    detection specifically for nvme_admin_async_event commands.
    
    Link: https://lore.kernel.org/r/20220603174329.63777-9-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>

scsi: lpfc: Fix port stuck in bypassed state after LIP in PT2PT topology [+ + +]
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>

scsi: pmcraid: Fix missing resource cleanup in error case [+ + +]
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>

scsi: vmw_pvscsi: Expand vcpuHint to 16 bits [+ + +]
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>

 
serial: 8250: Store to lsr_save_flags after lsr read [+ + +]
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>

 
siphash: use one source of truth for siphash permutations [+ + +]
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>

 
sparc: use fallback for random_get_entropy() instead of zero [+ + +]
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>

 
timekeeping: Add raw clock fallback for random_get_entropy() [+ + +]
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>

 
tty: goldfish: Fix free_irq() on remove [+ + +]
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>

 
um: use fallback for random_get_entropy() instead of zero [+ + +]
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>

 
usb: dwc2: Fix memory leak in dwc2_hcd_init [+ + +]
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>

usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe [+ + +]
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>

 
USB: serial: io_ti: add Agilent E5805A support [+ + +]
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>

USB: serial: option: add support for Cinterion MV31 with new baseline [+ + +]
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>

 
virtio-mmio: fix missing put_device() when vm_cmdline_parent registration failed [+ + +]
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>

 
virtio-pci: Remove wrong address verification in vp_del_vqs() [+ + +]
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>

 
x86/tsc: Use fallback for random_get_entropy() instead of zero [+ + +]
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>

 
x86: Remove arch_has_random, arch_has_random_seed [+ + +]
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>

 
xtensa: use fallback for random_get_entropy() instead of zero [+ + +]
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>