Update to internal 1.00-70

Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>

8 files changed, 411 insertions, 1 deletions

diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/0126-Adjust-soc-modules-probing-order.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/0126-Adjust-soc-modules-probing-order.patch
new file mode 100644
index 000000000..b9c1a2341
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/0126-Adjust-soc-modules-probing-order.patch
@@ -0,0 +1,39 @@
+From dcdfa13b5a5dd43a6e40c0f6091ac6b70f856450 Mon Sep 17 00:00:00 2001
+From: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
+Date: Mon, 4 Jan 2021 13:29:49 -0800
+Subject: [PATCH] Adjust soc modules probing order
+
+This commit moves object adding order for modules under soc to
+adjust module probing order.
+
+Don't updtream it. It should be a downstream patch.
+
+Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
+---
+ drivers/Makefile | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/Makefile b/drivers/Makefile
+index 297047d4ed9b..854e82d87727 100644
+--- a/drivers/Makefile
++++ b/drivers/Makefile
+@@ -38,9 +38,6 @@ obj-y				+= clk/
+ # really early.
+ obj-$(CONFIG_DMADEVICES)	+= dma/
+ 
+-# SOC specific infrastructure drivers.
+-obj-y				+= soc/
+-
+ obj-$(CONFIG_VIRTIO)		+= virtio/
+ obj-$(CONFIG_XEN)		+= xen/
+ 
+@@ -188,3 +185,6 @@ obj-$(CONFIG_INTERCONNECT)	+= interconnect/
+ obj-$(CONFIG_COUNTER)		+= counter/
+ obj-$(CONFIG_PECI)		+= peci/
+ obj-$(CONFIG_JTAG_ASPEED)	+= jtag/
++
++# SOC specific infrastructure drivers.
++obj-y				+= soc/
+-- 
+2.17.1
+
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1002-Filter-erroneous-adc-readings.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1002-Filter-erroneous-adc-readings.patch
index 9306ca9e2..34fd66e69 100644
--- a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1002-Filter-erroneous-adc-readings.patch
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1002-Filter-erroneous-adc-readings.patch
@@ -36,7 +36,7 @@ index c115797c4cc5..c1e775e764ca 100644
  
  #define ASPEED_ADC_CHANNELS_MAX	16
  #define ASPEED_ADC_RAW_VALUE_MAX	0x3ff
-+#define ASPEED_ADC_RAW_VALUE_DELTA_THRESHOLD	80
++#define ASPEED_ADC_RAW_VALUE_DELTA_THRESHOLD	40
  
  struct aspeed_adc_model_data {
  	const char *model_name;
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1003-Die_CPU-filter-first-zero-from-GetTemp.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1003-Die_CPU-filter-first-zero-from-GetTemp.patch
new file mode 100644
index 000000000..b7823ce14
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1003-Die_CPU-filter-first-zero-from-GetTemp.patch
@@ -0,0 +1,60 @@
+From 0d202fb06b873c5e258658462ac4fc01a673fd83 Mon Sep 17 00:00:00 2001
+From: Zhikui Ren <zhikui.ren@intel.com>
+Date: Mon, 11 Jan 2021 16:31:36 -0800
+Subject: [PATCH] Die_CPU: filter first zero from GetTemp
+
+Peci command GetTemp can return 0 during CPU reset.
+It does not have a have completion code either.
+Discard the first zero reading and return -ENODATA.
+Consecutive zeros will be returned so that real hot
+condition will still be detected and logged but possibly delayed
+by the sensor polling period, which is normally 500ms-1s.
+
+Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
+---
+ drivers/hwmon/peci-cputemp.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/drivers/hwmon/peci-cputemp.c b/drivers/hwmon/peci-cputemp.c
+index b633ea545644..19002f02bd91 100644
+--- a/drivers/hwmon/peci-cputemp.c
++++ b/drivers/hwmon/peci-cputemp.c
+@@ -15,6 +15,7 @@
+ 
+ struct temp_group {
+ 	struct peci_sensor_data		die;
++	u32 die_raw_prev;
+ 	struct peci_sensor_data		dts;
+ 	struct peci_sensor_data		tcontrol;
+ 	struct peci_sensor_data		tthrottle;
+@@ -129,6 +130,7 @@ static int get_die_temp(struct peci_cputemp *priv)
+ {
+ 	struct peci_get_temp_msg msg;
+ 	int ret;
++	bool discard = false;
+ 
+ 	if (!peci_sensor_need_update(&priv->temp.die))
+ 		return 0;
+@@ -139,6 +141,19 @@ static int get_die_temp(struct peci_cputemp *priv)
+ 	if (ret)
+ 		return ret;
+ 
++	/* GET_TEMP command does not have cc and can return zero during
++	 * cpu reset. Treat the first zero reading as data not available.
++	 * Consecutive zeros will be returned so true hot condition
++	 * is not be missed.
++	 */
++	if (msg.temp_raw == 0 && priv->temp.die_raw_prev != 0) {
++		pr_err("peci-cputemp_die: discard first 0 reading from GetTemp\n");
++		discard = true;
++	}
++	priv->temp.die_raw_prev = msg.temp_raw;
++	if (discard)
++		return -ENODATA;
++
+ 	/* Note that the tjmax should be available before calling it */
+ 	priv->temp.die.value = priv->temp.tjmax.value +
+ 			       (msg.temp_raw * 1000 / 64);
+-- 
+2.17.1
+
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1004-DTS_CPU-filter-first-zero-from-RdPkgConfig-10.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1004-DTS_CPU-filter-first-zero-from-RdPkgConfig-10.patch
new file mode 100644
index 000000000..aab6c3cea
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/1004-DTS_CPU-filter-first-zero-from-RdPkgConfig-10.patch
@@ -0,0 +1,64 @@
+From 68db4c74c43d4042b0b32bcd133121ab39b9b310 Mon Sep 17 00:00:00 2001
+From: Zhikui Ren <zhikui.ren@intel.com>
+Date: Tue, 2 Feb 2021 14:49:28 -0800
+Subject: [PATCH] DTS_CPU: filter first zero from RdPkgConfig 10
+
+Peci command GetPkgConfig 10 can return 0 (hot) with cc 0x40
+after cpu reset. Once pcode run time image is loaded
+and it returns 0x8000 as DTS margin data not ready
+Discard the first zero reading and return -ENODATA.
+Consecutive zeros will be returned so that real hot
+condition will still be detected and logged but possibly delayed
+by the sensor polling period, which is normally one second.
+
+Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
+---
+ drivers/hwmon/peci-cputemp.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/drivers/hwmon/peci-cputemp.c b/drivers/hwmon/peci-cputemp.c
+index 19002f02bd91..e1860779aa66 100644
+--- a/drivers/hwmon/peci-cputemp.c
++++ b/drivers/hwmon/peci-cputemp.c
+@@ -17,6 +17,7 @@ struct temp_group {
+ 	struct peci_sensor_data		die;
+ 	u32 die_raw_prev;
+ 	struct peci_sensor_data		dts;
++	u32 dts_raw_prev;
+ 	struct peci_sensor_data		tcontrol;
+ 	struct peci_sensor_data		tthrottle;
+ 	struct peci_sensor_data		tjmax;
+@@ -168,6 +169,7 @@ static int get_dts(struct peci_cputemp *priv)
+ 	s32 dts_margin;
+ 	u8  pkg_cfg[4];
+ 	int ret;
++	bool discard = false;
+ 
+ 	if (!peci_sensor_need_update(&priv->temp.dts))
+ 		return 0;
+@@ -181,6 +183,22 @@ static int get_dts(struct peci_cputemp *priv)
+ 
+ 	dts_margin = le16_to_cpup((__le16 *)pkg_cfg);
+ 
++	/* There is a small window (500us) for read dts_margin (RdPkgConfig 10)
++	 * to return cc 0x40, and dts_margin of 0 after cpu reset, before runtime
++	 * image is loaded to set it to 0x8000 (dts reading not ready).
++	 * DTS sensor is polled by user application at a slower rate than this window.
++	 * Treat the first zero reading as data not available.
++	 * Consecutive zeros will be returned so true hot condition
++	 * is not be missed.
++	 */
++	if (dts_margin == 0 && priv->temp.dts_raw_prev != 0) {
++		pr_err("peci-cputemp_dts: discard first 0 reading from RdPkgConfig 10\n");
++		discard = true;
++	}
++	priv->temp.dts_raw_prev = dts_margin;
++	if (discard)
++		return -ENODATA;
++
+ 	/**
+ 	 * Processors return a value of DTS reading in 10.6 format
+ 	 * (10 bits signed decimal, 6 bits fractional).
+-- 
+2.17.1
+
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-0465/0001-HID-core-Correctly-handle-ReportSize-being-zero.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-0465/0001-HID-core-Correctly-handle-ReportSize-being-zero.patch
new file mode 100644
index 000000000..d6550383b
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-0465/0001-HID-core-Correctly-handle-ReportSize-being-zero.patch
@@ -0,0 +1,65 @@
+From 667514df10a08e4a65cb88f5fd5ffeccd027c4af Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Sat, 29 Aug 2020 12:26:01 +0100
+Subject: [PATCH] HID: core: Correctly handle ReportSize being zero
+
+commit bce1305c0ece3dc549663605e567655dd701752c upstream.
+
+It appears that a ReportSize value of zero is legal, even if a bit
+non-sensical. Most of the HID code seems to handle that gracefully,
+except when computing the total size in bytes. When fed as input to
+memset, this leads to some funky outcomes.
+
+Detect the corner case and correctly compute the size.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/hid-core.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
+index 359616e3efbb..d2ecc9c45255 100644
+--- a/drivers/hid/hid-core.c
++++ b/drivers/hid/hid-core.c
+@@ -1597,6 +1597,17 @@ static void hid_output_field(const struct hid_device *hid,
+ 	}
+ }
+ 
++/*
++ * Compute the size of a report.
++ */
++static size_t hid_compute_report_size(struct hid_report *report)
++{
++	if (report->size)
++		return ((report->size - 1) >> 3) + 1;
++
++	return 0;
++}
++
+ /*
+  * Create a report. 'data' has to be allocated using
+  * hid_alloc_report_buf() so that it has proper size.
+@@ -1609,7 +1620,7 @@ void hid_output_report(struct hid_report *report, __u8 *data)
+ 	if (report->id > 0)
+ 		*data++ = report->id;
+ 
+-	memset(data, 0, ((report->size - 1) >> 3) + 1);
++	memset(data, 0, hid_compute_report_size(report));
+ 	for (n = 0; n < report->maxfield; n++)
+ 		hid_output_field(report->device, report->field[n], data);
+ }
+@@ -1739,7 +1750,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
+ 		csize--;
+ 	}
+ 
+-	rsize = ((report->size - 1) >> 3) + 1;
++	rsize = hid_compute_report_size(report);
+ 
+ 	if (report_enum->numbered && rsize >= HID_MAX_BUFFER_SIZE)
+ 		rsize = HID_MAX_BUFFER_SIZE - 1;
+-- 
+2.17.1
+
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-0466/0001-epoll-Keep-a-reference-on-files-added-to-the-check-l.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-0466/0001-epoll-Keep-a-reference-on-files-added-to-the-check-l.patch
new file mode 100644
index 000000000..0e2d0c53f
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-0466/0001-epoll-Keep-a-reference-on-files-added-to-the-check-l.patch
@@ -0,0 +1,68 @@
+From b158e91610c76c5d9c61c4e990d56405b62bf05a Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Wed, 19 Aug 2020 17:12:17 +0100
+Subject: [PATCH] epoll: Keep a reference on files added to the check list
+
+commit a9ed4a6560b8562b7e2e2bed9527e88001f7b682 upstream.
+
+When adding a new fd to an epoll, and that this new fd is an
+epoll fd itself, we recursively scan the fds attached to it
+to detect cycles, and add non-epool files to a "check list"
+that gets subsequently parsed.
+
+However, this check list isn't completely safe when deletions
+can happen concurrently. To sidestep the issue, make sure that
+a struct file placed on the check list sees its f_count increased,
+ensuring that a concurrent deletion won't result in the file
+disapearing from under our feet.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/eventpoll.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/fs/eventpoll.c b/fs/eventpoll.c
+index 6307c1d883e0..b53ae571f064 100644
+--- a/fs/eventpoll.c
++++ b/fs/eventpoll.c
+@@ -1991,9 +1991,11 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests)
+ 			 * not already there, and calling reverse_path_check()
+ 			 * during ep_insert().
+ 			 */
+-			if (list_empty(&epi->ffd.file->f_tfile_llink))
++			if (list_empty(&epi->ffd.file->f_tfile_llink)) {
++				get_file(epi->ffd.file);
+ 				list_add(&epi->ffd.file->f_tfile_llink,
+ 					 &tfile_check_list);
++			}
+ 		}
+ 	}
+ 	mutex_unlock(&ep->mtx);
+@@ -2037,6 +2039,7 @@ static void clear_tfile_check_list(void)
+ 		file = list_first_entry(&tfile_check_list, struct file,
+ 					f_tfile_llink);
+ 		list_del_init(&file->f_tfile_llink);
++		fput(file);
+ 	}
+ 	INIT_LIST_HEAD(&tfile_check_list);
+ }
+@@ -2196,9 +2199,11 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
+ 					clear_tfile_check_list();
+ 					goto error_tgt_fput;
+ 				}
+-			} else
++			} else {
++				get_file(tf.file);
+ 				list_add(&tf.file->f_tfile_llink,
+ 							&tfile_check_list);
++			}
+ 			mutex_lock_nested(&ep->mtx, 0);
+ 			if (is_file_epoll(tf.file)) {
+ 				tep = tf.file->private_data;
+-- 
+2.17.1
+
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-27825/0001-tracing-Fix-race-in-trace_open-and-buffer-resize-cal.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-27825/0001-tracing-Fix-race-in-trace_open-and-buffer-resize-cal.patch
new file mode 100644
index 000000000..8313c0533
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-27825/0001-tracing-Fix-race-in-trace_open-and-buffer-resize-cal.patch
@@ -0,0 +1,60 @@
+From d8fb64e4164d3f4c89eb58c27b2472a052359823 Mon Sep 17 00:00:00 2001
+From: Gaurav Kohli <gkohli@codeaurora.org>
+Date: Tue, 6 Oct 2020 15:03:53 +0530
+Subject: [PATCH] tracing: Fix race in trace_open and buffer resize call
+
+Below race can come, if trace_open and resize of
+cpu buffer is running parallely on different cpus
+CPUX                                CPUY
+				    ring_buffer_resize
+				    atomic_read(&buffer->resize_disabled)
+tracing_open
+tracing_reset_online_cpus
+ring_buffer_reset_cpu
+rb_reset_cpu
+				    rb_update_pages
+				    remove/insert pages
+resetting pointer
+
+This race can cause data abort or some times infinte loop in
+rb_remove_pages and rb_insert_pages while checking pages
+for sanity.
+
+Take buffer lock to fix this.
+
+Link: https://lkml.kernel.org/r/1601976833-24377-1-git-send-email-gkohli@codeaurora.org
+
+Cc: stable@vger.kernel.org
+Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU")
+Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+---
+ kernel/trace/ring_buffer.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
+index 4bf050fcfe3b..6a790901270f 100644
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -4406,6 +4406,9 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, int cpu)
+ 	if (!cpumask_test_cpu(cpu, buffer->cpumask))
+ 		return;
+ 
++	/* prevent another thread from changing buffer sizes */
++	mutex_lock(&buffer->mutex);
++
+ 	atomic_inc(&buffer->resize_disabled);
+ 	atomic_inc(&cpu_buffer->record_disabled);
+ 
+@@ -4428,6 +4431,8 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, int cpu)
+ 
+ 	atomic_dec(&cpu_buffer->record_disabled);
+ 	atomic_dec(&buffer->resize_disabled);
++
++	mutex_unlock(&buffer->mutex);
+ }
+ EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
+ 
+-- 
+2.17.1
+
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29569/0001-xen-blkback-set-ring-xenblkd-to-null-after-kthread-stop.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29569/0001-xen-blkback-set-ring-xenblkd-to-null-after-kthread-stop.patch
new file mode 100644
index 000000000..2c55e4f46
--- /dev/null
+++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2020-29569/0001-xen-blkback-set-ring-xenblkd-to-null-after-kthread-stop.patch
@@ -0,0 +1,54 @@
+From 1c728719a4da6e654afb9cc047164755072ed7c9 Mon Sep 17 00:00:00 2001
+From: Pawel Wieczorkiewicz <wipawel@amazon.de>
+Date: Mon, 14 Dec 2020 10:25:57 +0100
+Subject: xen-blkback: set ring->xenblkd to NULL after kthread_stop()
+
+CVE-2020-29569 fix: This is XSA-350
+commit id: 1c728719a4da6e654afb9cc047164755072ed7c9
+
+When xen_blkif_disconnect() is called, the kernel thread behind the
+block interface is stopped by calling kthread_stop(ring->xenblkd).
+The ring->xenblkd thread pointer being non-NULL determines if the
+thread has been already stopped.
+Normally, the thread's function xen_blkif_schedule() sets the
+ring->xenblkd to NULL, when the thread's main loop ends.
+
+However, when the thread has not been started yet (i.e.
+wake_up_process() has not been called on it), the xen_blkif_schedule()
+function would not be called yet.
+
+In such case the kthread_stop() call returns -EINTR and the
+ring->xenblkd remains dangling.
+When this happens, any consecutive call to xen_blkif_disconnect (for
+example in frontend_changed() callback) leads to a kernel crash in
+kthread_stop() (e.g. NULL pointer dereference in exit_creds()).
+
+This is XSA-350.
+
+Cc: <stable@vger.kernel.org> # 4.12
+Fixes: a24fa22ce22a ("xen/blkback: don't use xen_blkif_get() in xen-blkback kthread")
+Reported-by: Olivier Benjamin <oliben@amazon.com>
+Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
+Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
+Reviewed-by: Julien Grall <jgrall@amazon.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+---
+ drivers/block/xen-blkback/xenbus.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+(limited to 'drivers/block/xen-blkback/xenbus.c')
+
+diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
+index 1d8b8d24496c3..9860d4842f36c 100644
+--- a/drivers/block/xen-blkback/xenbus.c
++++ b/drivers/block/xen-blkback/xenbus.c
+@@ -274,6 +274,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
+ 
+ 		if (ring->xenblkd) {
+ 			kthread_stop(ring->xenblkd);
++			ring->xenblkd = NULL;
+ 			wake_up(&ring->shutdown_wq);
+ 		}
+ 
+--