Update to 4.19.101

Cleanup debian/changelog file

Drop "random: try to actively add entropy rather than passively wait for it"
This commit is contained in:
Salvatore Bonaccorso 2020-02-21 12:14:32 +01:00
parent c2975cd055
commit f003f0dba9
3 changed files with 50 additions and 147 deletions

51
debian/changelog vendored
View File

@ -1,4 +1,4 @@
linux (4.19.100-1) UNRELEASED; urgency=medium
linux (4.19.101-1) UNRELEASED; urgency=medium
* New upstream stable update:
https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.99
@ -515,6 +515,55 @@ linux (4.19.100-1) UNRELEASED; urgency=medium
- mm/memunmap: don't access uninitialized memmap in memunmap_pages()
- mm/memory_hotplug: fix try_offline_node()
- mm/memory_hotplug: shrink zones when offlining memory
https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.101
- orinoco_usb: fix interface sanity check
- rsi_91x_usb: fix interface sanity check
- usb: dwc3: pci: add ID for the Intel Comet Lake -V variant
- USB: serial: ir-usb: add missing endpoint sanity check
- USB: serial: ir-usb: fix link-speed handling
- USB: serial: ir-usb: fix IrLAP framing
- [arm64,armhf] usb: dwc3: turn off VBUS when leaving host mode
- staging: wlan-ng: ensure error return is actually returned
- [x86] staging: vt6656: correct packet types for CTS protect, mode.
- [x86] staging: vt6656: use NULLFUCTION stack on mac80211
- [x86] staging: vt6656: Fix false Tx excessive retries reporting.
- [arm64,armel] serial: 8250_bcm2835aux: Fix line mismatch on driver
unbind
- component: do not dereference opaque pointer in debugfs
- mei: me: add comet point (lake) H device ids
- crypto: chelsio - fix writing tfm flags to wrong place
- cifs: Fix memory allocation in __smb2_handle_cancelled_cmd()
- ath9k: fix storage endpoint lookup
- brcmfmac: fix interface sanity check
- rtl8xxxu: fix interface sanity check
- zd1211rw: fix storage endpoint lookup
- net_sched: ematch: reject invalid TCF_EM_SIMPLE
- net_sched: fix ops->bind_class() implementations
- HID: multitouch: Add LG MELF0410 I2C touchscreen support
- HID: Add quirk for Xin-Mo Dual Controller
- HID: ite: Add USB id match for Acer SW5-012 keyboard dock
- HID: Add quirk for incorrect input length on Lenovo Y720
- drivers/hid/hid-multitouch.c: fix a possible null pointer access.
- [arm64] phy: qcom-qmp: Increase PHY ready timeout
- drivers/net/b44: Change to non-atomic bit operations on pwol_mask
- [i386] net: wan: sdla: Fix cast from pointer to integer of different
size
- [arm64] gpio: max77620: Add missing dependency on GPIOLIB_IRQCHIP
- atm: eni: fix uninitialized variable warning
- HID: steam: Fix input device disappearing
- [x86] platform/x86: dell-laptop: disable kbd backlight on Inspiron 10xx
- PCI: Add DMA alias quirk for Intel VCA NTB
- [amd64] iommu: Support multiple PCI DMA aliases in IRQ Remapping
- usb-storage: Disable UAS on JMicron SATA enclosure
- sched/fair: Add tmp_alone_branch assertion
- sched/fair: Fix insertion in rq->leaf_cfs_rq_list
- rsi: fix use-after-free on probe errors
- rsi: fix memory leak on failed URB submission
- rsi: fix non-atomic allocation in completion handler
- crypto: af_alg - Use bh_lock_sock in sk_destruct
- block: cleanup __blkdev_issue_discard()
- block: fix 32 bit overflow in __blkdev_issue_discard()
- [arm64] KVM: Write arch.mdcr_el2 changes since last vcpu_load on VHE
[ Salvatore Bonaccorso ]
* vfs: fix do_last() regression

View File

@ -1,143 +0,0 @@
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 28 Sep 2019 16:53:52 -0700
Subject: [PATCH] random: try to actively add entropy rather than passively
wait for it
Origin: https://git.kernel.org/linus/50ee7529ec4500c88f8664560770a7a1b65db72b
Bug-Debian: https://bugs.debian.org/948519
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
caused a bootup regression due to lack of entropy at bootup together
with arguably broken user space that was asking for secure random
numbers when it really didn't need to.
See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug").
This aims to solve the issue by actively generating entropy noise using
the CPU cycle counter when waiting for the random number generator to
initialize. This only works when you have a high-frequency time stamp
counter available, but that's the case on all modern x86 CPU's, and on
most other modern CPU's too.
What we do is to generate jitter entropy from the CPU cycle counter
under a somewhat complex load: calling the scheduler while also
guaranteeing a certain amount of timing noise by also triggering a
timer.
I'm sure we can tweak this, and that people will want to look at other
alternatives, but there's been a number of papers written on jitter
entropy, and this should really be fairly conservative by crediting one
bit of entropy for every timer-induced jump in the cycle counter. Not
because the timer itself would be all that unpredictable, but because
the interaction between the timer and the loop is going to be.
Even if (and perhaps particularly if) the timer actually happens on
another CPU, the cacheline interaction between the loop that reads the
cycle counter and the timer itself firing is going to add perturbations
to the cycle counter values that get mixed into the entropy pool.
As Thomas pointed out, with a modern out-of-order CPU, even quite simple
loops show a fair amount of hard-to-predict timing variability even in
the absense of external interrupts. But this tries to take that further
by actually having a fairly complex interaction.
This is not going to solve the entropy issue for architectures that have
no CPU cycle counter, but it's not clear how (and if) that is solvable,
and the hardware in question is largely starting to be irrelevant. And
by doing this we can at least avoid some of the even more contentious
approaches (like making the entropy waiting time out in order to avoid
the possibly unbounded waiting).
Cc: Ahmed Darwish <darwish.07@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Nicholas Mc Guire <hofrat@opentech.at>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
drivers/char/random.c | 62 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
Index: linux/drivers/char/random.c
===================================================================
--- linux.orig/drivers/char/random.c
+++ linux/drivers/char/random.c
@@ -1653,6 +1653,56 @@ void get_random_bytes(void *buf, int nby
}
EXPORT_SYMBOL(get_random_bytes);
+
+/*
+ * Each time the timer fires, we expect that we got an unpredictable
+ * jump in the cycle counter. Even if the timer is running on another
+ * CPU, the timer activity will be touching the stack of the CPU that is
+ * generating entropy..
+ *
+ * Note that we don't re-arm the timer in the timer itself - we are
+ * happy to be scheduled away, since that just makes the load more
+ * complex, but we do not want the timer to keep ticking unless the
+ * entropy loop is running.
+ *
+ * So the re-arming always happens in the entropy loop itself.
+ */
+static void entropy_timer(struct timer_list *t)
+{
+ credit_entropy_bits(&input_pool, 1);
+}
+
+/*
+ * If we have an actual cycle counter, see if we can
+ * generate enough entropy with timing noise
+ */
+static void try_to_generate_entropy(void)
+{
+ struct {
+ unsigned long now;
+ struct timer_list timer;
+ } stack;
+
+ stack.now = random_get_entropy();
+
+ /* Slow counter - or none. Don't even bother */
+ if (stack.now == random_get_entropy())
+ return;
+
+ timer_setup_on_stack(&stack.timer, entropy_timer, 0);
+ while (!crng_ready()) {
+ if (!timer_pending(&stack.timer))
+ mod_timer(&stack.timer, jiffies+1);
+ mix_pool_bytes(&input_pool, &stack.now, sizeof(stack.now));
+ schedule();
+ stack.now = random_get_entropy();
+ }
+
+ del_timer_sync(&stack.timer);
+ destroy_timer_on_stack(&stack.timer);
+ mix_pool_bytes(&input_pool, &stack.now, sizeof(stack.now));
+}
+
/*
* Wait for the urandom pool to be seeded and thus guaranteed to supply
* cryptographically secure random numbers. This applies to: the /dev/urandom
@@ -1667,7 +1717,17 @@ int wait_for_random_bytes(void)
{
if (likely(crng_ready()))
return 0;
- return wait_event_interruptible(crng_init_wait, crng_ready());
+
+ do {
+ int ret;
+ ret = wait_event_interruptible_timeout(crng_init_wait, crng_ready(), HZ);
+ if (ret)
+ return ret > 0 ? 0 : ret;
+
+ try_to_generate_entropy();
+ } while (!crng_ready());
+
+ return 0;
}
EXPORT_SYMBOL(wait_for_random_bytes);

View File

@ -299,7 +299,4 @@ bugfix/all/wimax-i2400-fix-memory-leak.patch
bugfix/all/wimax-i2400-fix-memory-leak-in-i2400m_op_rfkill_sw_toggle.patch
bugfix/all/vfs-fix-do_last-regression.patch
# Backported change to provide boot-time entropy
bugfix/all/random-try-to-actively-add-entropy-rather-than-passi.patch
# ABI maintenance