Merge remote-tracking branch 'origin/f29' into f29-user-thl-vanilla-fedora

5 files changed, 425 insertions, 0 deletions

diff --git a/0001-KVM-x86-nVMX-close-leak-of-L0-s-x2APIC-MSRs-CVE-2019.patch b/0001-KVM-x86-nVMX-close-leak-of-L0-s-x2APIC-MSRs-CVE-2019.patch
new file mode 100644
index 000000000..f8e81e7af
--- /dev/null
+++ b/0001-KVM-x86-nVMX-close-leak-of-L0-s-x2APIC-MSRs-CVE-2019.patch
@@ -0,0 +1,134 @@
+From acff78477b9b4f26ecdf65733a4ed77fe837e9dc Mon Sep 17 00:00:00 2001
+From: Marc Orr <marcorr@google.com>
+Date: Mon, 1 Apr 2019 23:55:59 -0700
+Subject: [PATCH] KVM: x86: nVMX: close leak of L0's x2APIC MSRs
+ (CVE-2019-3887)
+
+The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the
+x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a
+result, we discovered the potential for a buggy or malicious L1 to get
+access to L0's x2APIC MSRs, via an L2, as follows.
+
+1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl
+variable, in nested_vmx_prepare_msr_bitmap() to become true.
+2. L1 disables "virtualize x2APIC mode" in VMCS12.
+3. L1 enables "APIC-register virtualization" in VMCS12.
+
+Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then
+set "virtualize x2APIC mode" to 0 in VMCS02. Oops.
+
+This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR
+intercepts with VMCS12's "virtualize x2APIC mode" control.
+
+The scenario outlined above and fix prescribed here, were verified with
+a related patch in kvm-unit-tests titled "Add leak scenario to
+virt_x2apic_mode_test".
+
+Note, it looks like this issue may have been introduced inadvertently
+during a merge---see 15303ba5d1cd.
+
+Signed-off-by: Marc Orr <marcorr@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+---
+ arch/x86/kvm/vmx/nested.c | 72 ++++++++++++++++++++++++---------------
+ 1 file changed, 44 insertions(+), 28 deletions(-)
+
+diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
+index 153e539c29c9..897d70e3d291 100644
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -500,6 +500,17 @@ static void nested_vmx_disable_intercept_for_msr(unsigned long *msr_bitmap_l1,
+ 	}
+ }
+
++static inline void enable_x2apic_msr_intercepts(unsigned long *msr_bitmap) {
++	int msr;
++
++	for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
++		unsigned word = msr / BITS_PER_LONG;
++
++		msr_bitmap[word] = ~0;
++		msr_bitmap[word + (0x800 / sizeof(long))] = ~0;
++	}
++}
++
+ /*
+  * Merge L0's and L1's MSR bitmap, return false to indicate that
+  * we do not use the hardware.
+@@ -541,39 +552,44 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
+ 		return false;
+
+ 	msr_bitmap_l1 = (unsigned long *)kmap(page);
+-	if (nested_cpu_has_apic_reg_virt(vmcs12)) {
+-		/*
+-		 * L0 need not intercept reads for MSRs between 0x800 and 0x8ff, it
+-		 * just lets the processor take the value from the virtual-APIC page;
+-		 * take those 256 bits directly from the L1 bitmap.
+-		 */
+-		for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
+-			unsigned word = msr / BITS_PER_LONG;
+-			msr_bitmap_l0[word] = msr_bitmap_l1[word];
+-			msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0;
+-		}
+-	} else {
+-		for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
+-			unsigned word = msr / BITS_PER_LONG;
+-			msr_bitmap_l0[word] = ~0;
+-			msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0;
+-		}
+-	}
+
+-	nested_vmx_disable_intercept_for_msr(
+-		msr_bitmap_l1, msr_bitmap_l0,
+-		X2APIC_MSR(APIC_TASKPRI),
+-		MSR_TYPE_W);
++	/*
++	 * To keep the control flow simple, pay eight 8-byte writes (sixteen
++	 * 4-byte writes on 32-bit systems) up front to enable intercepts for
++	 * the x2APIC MSR range and selectively disable them below.
++	 */
++	enable_x2apic_msr_intercepts(msr_bitmap_l0);
++
++	if (nested_cpu_has_virt_x2apic_mode(vmcs12)) {
++		if (nested_cpu_has_apic_reg_virt(vmcs12)) {
++			/*
++			 * L0 need not intercept reads for MSRs between 0x800
++			 * and 0x8ff, it just lets the processor take the value
++			 * from the virtual-APIC page; take those 256 bits
++			 * directly from the L1 bitmap.
++			 */
++			for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
++				unsigned word = msr / BITS_PER_LONG;
++
++				msr_bitmap_l0[word] = msr_bitmap_l1[word];
++			}
++		}
+
+-	if (nested_cpu_has_vid(vmcs12)) {
+-		nested_vmx_disable_intercept_for_msr(
+-			msr_bitmap_l1, msr_bitmap_l0,
+-			X2APIC_MSR(APIC_EOI),
+-			MSR_TYPE_W);
+ 		nested_vmx_disable_intercept_for_msr(
+ 			msr_bitmap_l1, msr_bitmap_l0,
+-			X2APIC_MSR(APIC_SELF_IPI),
++			X2APIC_MSR(APIC_TASKPRI),
+ 			MSR_TYPE_W);
++
++		if (nested_cpu_has_vid(vmcs12)) {
++			nested_vmx_disable_intercept_for_msr(
++				msr_bitmap_l1, msr_bitmap_l0,
++				X2APIC_MSR(APIC_EOI),
++				MSR_TYPE_W);
++			nested_vmx_disable_intercept_for_msr(
++				msr_bitmap_l1, msr_bitmap_l0,
++				X2APIC_MSR(APIC_SELF_IPI),
++				MSR_TYPE_W);
++		}
+ 	}
+
+ 	if (spec_ctrl)
+-- 
+2.20.1
+
diff --git a/0001-KVM-x86-nVMX-fix-x2APIC-VTPR-read-intercept.patch b/0001-KVM-x86-nVMX-fix-x2APIC-VTPR-read-intercept.patch
new file mode 100644
index 000000000..f73a7f336
--- /dev/null
+++ b/0001-KVM-x86-nVMX-fix-x2APIC-VTPR-read-intercept.patch
@@ -0,0 +1,46 @@
+From c73f4c998e1fd4249b9edfa39e23f4fda2b9b041 Mon Sep 17 00:00:00 2001
+From: Marc Orr <marcorr@google.com>
+Date: Mon, 1 Apr 2019 23:56:00 -0700
+Subject: [PATCH] KVM: x86: nVMX: fix x2APIC VTPR read intercept
+
+Referring to the "VIRTUALIZING MSR-BASED APIC ACCESSES" chapter of the
+SDM, when "virtualize x2APIC mode" is 1 and "APIC-register
+virtualization" is 0, a RDMSR of 808H should return the VTPR from the
+virtual APIC page.
+
+However, for nested, KVM currently fails to disable the read intercept
+for this MSR. This means that a RDMSR exit takes precedence over
+"virtualize x2APIC mode", and KVM passes through L1's TPR to L2,
+instead of sourcing the value from L2's virtual APIC page.
+
+This patch fixes the issue by disabling the read intercept, in VMCS02,
+for the VTPR when "APIC-register virtualization" is 0.
+
+The issue described above and fix prescribed here, were verified with
+a related patch in kvm-unit-tests titled "Test VMX's virtualize x2APIC
+mode w/ nested".
+
+Signed-off-by: Marc Orr <marcorr@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Fixes: c992384bde84f ("KVM: vmx: speed up MSR bitmap merge")
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+---
+ arch/x86/kvm/vmx/nested.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
+index 897d70e3d291..7ec9bb1dd723 100644
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -578,7 +578,7 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu,
+ 		nested_vmx_disable_intercept_for_msr(
+ 			msr_bitmap_l1, msr_bitmap_l0,
+ 			X2APIC_MSR(APIC_TASKPRI),
+-			MSR_TYPE_W);
++			MSR_TYPE_R | MSR_TYPE_W);
+
+ 		if (nested_cpu_has_vid(vmcs12)) {
+ 			nested_vmx_disable_intercept_for_msr(
+-- 
+2.20.1
+
diff --git a/0001-drm-i915-dp-revert-back-to-max-link-rate-and-lane-co.patch b/0001-drm-i915-dp-revert-back-to-max-link-rate-and-lane-co.patch
new file mode 100644
index 000000000..ab16d1aa0
--- /dev/null
+++ b/0001-drm-i915-dp-revert-back-to-max-link-rate-and-lane-co.patch
@@ -0,0 +1,132 @@
+From 1b58e7d454035355aaa0f29d31366669c13643e7 Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Fri, 5 Apr 2019 10:19:31 +0300
+Subject: [PATCH] drm/i915/dp: revert back to max link rate and lane count on
+ eDP
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
+Cc: Jani Nikula <jani.nikula@intel.com>
+
+Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
+and narrow") started to optize the eDP 1.4+ link config, both per spec
+and as preparation for display stream compression support.
+
+Sadly, we again face panels that flat out fail with parameters they
+claim to support. Revert, and go back to the drawing board.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
+Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow")
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Manasi Navare <manasi.d.navare@intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: Matt Atwood <matthew.s.atwood@intel.com>
+Cc: "Lee, Shawn C" <shawn.c.lee@intel.com>
+Cc: Dave Airlie <airlied@gmail.com>
+Cc: intel-gfx@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v5.0+
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+---
+ drivers/gpu/drm/i915/intel_dp.c | 69 +++++----------------------------
+ 1 file changed, 10 insertions(+), 59 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
+index 22a746..dcd1df 100644
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -1845,42 +1845,6 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
+ 	return false;
+ }
+ 
+-/* Optimize link config in order: max bpp, min lanes, min clock */
+-static bool
+-intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+-				  struct intel_crtc_state *pipe_config,
+-				  const struct link_config_limits *limits)
+-{
+-	struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
+-	int bpp, clock, lane_count;
+-	int mode_rate, link_clock, link_avail;
+-
+-	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+-		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+-						   bpp);
+-
+-		for (lane_count = limits->min_lane_count;
+-		     lane_count <= limits->max_lane_count;
+-		     lane_count <<= 1) {
+-			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
+-				link_clock = intel_dp->common_rates[clock];
+-				link_avail = intel_dp_max_data_rate(link_clock,
+-								    lane_count);
+-
+-				if (mode_rate <= link_avail) {
+-					pipe_config->lane_count = lane_count;
+-					pipe_config->pipe_bpp = bpp;
+-					pipe_config->port_clock = link_clock;
+-
+-					return true;
+-				}
+-			}
+-		}
+-	}
+-
+-	return false;
+-}
+-
+ static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
+ {
+ 	int i, num_bpc;
+@@ -2013,15 +1977,13 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
+ 	limits.min_bpp = 6 * 3;
+ 	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
+ 
+-	if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
++	if (intel_dp_is_edp(intel_dp)) {
+ 		/*
+ 		 * Use the maximum clock and number of lanes the eDP panel
+-		 * advertizes being capable of. The eDP 1.3 and earlier panels
+-		 * are generally designed to support only a single clock and
+-		 * lane configuration, and typically these values correspond to
+-		 * the native resolution of the panel. With eDP 1.4 rate select
+-		 * and DSC, this is decreasingly the case, and we need to be
+-		 * able to select less than maximum link config.
++		 * advertizes being capable of. The panels are generally
++		 * designed to support only a single clock and lane
++		 * configuration, and typically these values correspond to the
++		 * native resolution of the panel.
+ 		 */
+ 		limits.min_lane_count = limits.max_lane_count;
+ 		limits.min_clock = limits.max_clock;
+@@ -2035,22 +1997,11 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
+ 		      intel_dp->common_rates[limits.max_clock],
+ 		      limits.max_bpp, adjusted_mode->crtc_clock);
+ 
+-	if (intel_dp_is_edp(intel_dp))
+-		/*
+-		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
+-		 * section A.1: "It is recommended that the minimum number of
+-		 * lanes be used, using the minimum link rate allowed for that
+-		 * lane configuration."
+-		 *
+-		 * Note that we use the max clock and lane count for eDP 1.3 and
+-		 * earlier, and fast vs. wide is irrelevant.
+-		 */
+-		ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config,
+-							&limits);
+-	else
+-		/* Optimize for slow and wide. */
+-		ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config,
+-							&limits);
++	/*
++	 * Optimize for slow and wide. This is the place to add alternative
++	 * optimization policy.
++	 */
++	ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
+ 
+ 	/* enable compression if the mode doesn't fit available BW */
+ 	if (!ret) {
+-- 
+2.20.1
+
diff --git a/efi-lockdown.patch b/efi-lockdown.patch
index a4b602b2a..775a64d20 100644
--- a/efi-lockdown.patch
+++ b/efi-lockdown.patch
@@ -518,6 +518,109 @@ index f35ffdd096ad..2615669dbf03 100644
 -- 
 2.14.3
 
+From e5709852ca1e9ed443d9abebcb35cbc2f0d9d987 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Mon, 18 Feb 2019 12:44:58 +0000
+Subject: [PATCH 02/27] Enforce module signatures if the kernel is locked down
+
+If the kernel is locked down, require that all modules have valid
+signatures that we can verify.
+
+I have adjusted the errors generated:
+
+ (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
+     ENOKEY), then:
+
+     (a) If signatures are enforced then EKEYREJECTED is returned.
+
+     (b) If there's no signature or we can't check it, but the kernel is
+	 locked down then EPERM is returned (this is then consistent with
+	 other lockdown cases).
+
+ (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
+     the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
+     return the error we got.
+
+Note that the X.509 code doesn't check for key expiry as the RTC might not
+be valid or might not have been transferred to the kernel's clock yet.
+
+ [Modified by Matthew Garrett to remove the IMA integration. This will
+  be replaced with integration with the IMA architecture policy
+  patchset.]
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+Reviewed-by: Jiri Bohac <jbohac@suse.cz>
+Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
+Cc: Jessica Yu <jeyu@kernel.org>
+---
+ kernel/module.c | 39 ++++++++++++++++++++++++++++++++-------
+ 1 file changed, 32 insertions(+), 7 deletions(-)
+
+diff --git a/kernel/module.c b/kernel/module.c
+index 2ad1b5239910..9a377c6ea200 100644
+--- a/kernel/module.c
++++ b/kernel/module.c
+@@ -2767,8 +2767,9 @@ static inline void kmemleak_load_module(const struct module *mod,
+ #ifdef CONFIG_MODULE_SIG
+ static int module_sig_check(struct load_info *info, int flags)
+ {
+-	int err = -ENOKEY;
++	int err = -ENODATA;
+ 	const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
++	const char *reason;
+ 	const void *mod = info->hdr;
+ 
+ 	/*
+@@ -2783,16 +2784,40 @@ static int module_sig_check(struct load_info *info, int flags)
+ 		err = mod_verify_sig(mod, info);
+ 	}
+ 
+-	if (!err) {
++	switch (err) {
++	case 0:
+ 		info->sig_ok = true;
+ 		return 0;
+-	}
+ 
+-	/* Not having a signature is only an error if we're strict. */
+-	if (err == -ENOKEY && !is_module_sig_enforced())
+-		err = 0;
++		/* We don't permit modules to be loaded into trusted kernels
++		 * without a valid signature on them, but if we're not
++		 * enforcing, certain errors are non-fatal.
++		 */
++	case -ENODATA:
++		reason = "Loading of unsigned module";
++		goto decide;
++	case -ENOPKG:
++		reason = "Loading of module with unsupported crypto";
++		goto decide;
++	case -ENOKEY:
++		reason = "Loading of module with unavailable key";
++	decide:
++		if (is_module_sig_enforced()) {
++			pr_notice("%s is rejected\n", reason);
++			return -EKEYREJECTED;
++		}
+ 
+-	return err;
++		if (kernel_is_locked_down(reason))
++			return -EPERM;
++		return 0;
++
++		/* All other errors are fatal, including nomem, unparseable
++		 * signatures and signature check failures - even if signatures
++		 * aren't required.
++		 */
++	default:
++		return err;
++	}
+ }
+ #else /* !CONFIG_MODULE_SIG */
+ static int module_sig_check(struct load_info *info, int flags)
+-- 
+2.21.0
+
 From 7948946e19294e7560c81b177b2788d21ed79f59 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <mjg59@srcf.ucam.org>
 Date: Mon, 9 Apr 2018 09:52:46 +0100
diff --git a/kernel.spec b/kernel.spec
index 6207ae15b..9aee10abf 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -634,6 +634,13 @@ Patch516: 0001-inotify-Fix-fsnotify_mark-refcount-leak-in-inotify_u.patch
 # CVE-2019-3882 rhbz 1689426 1695571
 Patch517: vfio-type1-limit-dma-mappings-per-container.patch
 
+# CVE-2019 rhbz 1695044 1697187
+Patch518: 0001-KVM-x86-nVMX-close-leak-of-L0-s-x2APIC-MSRs-CVE-2019.patch
+Patch519: 0001-KVM-x86-nVMX-fix-x2APIC-VTPR-read-intercept.patch
+
+# drm fix
+Patch520: 0001-drm-i915-dp-revert-back-to-max-link-rate-and-lane-co.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -1913,6 +1920,9 @@ fi
 * Mon Apr 08 2019 Laura Abbott <labbott@redhat.com> - 5.0.7-200
 - Linux v5.0.7
 
+* Mon Apr 08 2019 Justin M. Forbes <jforbes@fedoraproject.org>
+- Fix CVE-2019 (rhbz 1695044 1697187)
+
 * Wed Apr 03 2019 Laura Abbott <labbott@redhat.com> - 5.0.6-200
 - Linux v5.0.6