From: Greg Kroah-Hartman Date: Sun, 3 Oct 2021 14:21:28 +0000 (+0200) Subject: 5.14-stable patches X-Git-Tag: v4.4.286~52 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=21930942f036e890cc4eac38906b715451dcca00;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: drm-amd-display-fix-display-flicker-on-embedded-panels.patch drm-amd-display-initialize-backlight_ramping_override-to-false.patch drm-amd-display-pass-pci-deviceid-into-dc.patch drm-amdgpu-check-tiling-flags-when-creating-fb-on-gfx8.patch drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch drm-amdgpu-force-exit-gfxoff-on-sdma-resume-for-rmb-s0ix.patch kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch kvm-nvmx-fix-nested-bus-lock-vm-exit.patch kvm-sev-acquire-vcpu-mutex-when-updating-vmsa.patch kvm-sev-allow-some-commands-for-mirror-vm.patch kvm-sev-pin-guest-memory-for-write-for-receive_update_data.patch kvm-sev-update-svm_vm_copy_asid_from-for-sev-es.patch kvm-svm-fix-missing-sev_decommission-in-sev_receive_start.patch kvm-vmx-fix-a-tsx_ctrl_cpuid_clear-field-mask-issue.patch kvm-x86-clear-kvm-s-cached-guest-cr3-at-reset-init.patch kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch kvm-x86-swap-order-of-cpuid-entry-index-vs.-significant-flag-checks.patch media-ir_toy-prevent-device-from-hanging-during-transmit.patch mmc-renesas_sdhi-fix-regression-with-hard-reset-on-old-sdhis.patch nbd-use-shifts-rather-than-multiplies.patch platform-x86-intel-hid-add-dmi-switches-allow-list.patch ptp-fix-ptp_kvm_getcrosststamp-issue-for-x86-ptp_kvm.patch rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch rdma-cma-ensure-rdma_addr_cancel-happens-before-issuing-more-requests.patch x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch --- diff --git a/queue-5.14/drm-amd-display-fix-display-flicker-on-embedded-panels.patch b/queue-5.14/drm-amd-display-fix-display-flicker-on-embedded-panels.patch new file mode 100644 index 00000000000..66527c959cb --- /dev/null +++ b/queue-5.14/drm-amd-display-fix-display-flicker-on-embedded-panels.patch @@ -0,0 +1,55 @@ +From 083fa05bbaf65a01866b5440031c822e32ad7510 Mon Sep 17 00:00:00 2001 +From: Praful Swarnakar +Date: Wed, 22 Sep 2021 23:01:29 +0530 +Subject: drm/amd/display: Fix Display Flicker on embedded panels + +From: Praful Swarnakar + +commit 083fa05bbaf65a01866b5440031c822e32ad7510 upstream. + +[Why] +ASSR is dependent on Signed PSP Verstage to enable Content +Protection for eDP panels. Unsigned PSP verstage is used +during development phase causing ASSR to FAIL. +As a result, link training is performed with +DP_PANEL_MODE_DEFAULT instead of DP_PANEL_MODE_EDP for +eDP panels that causes display flicker on some panels. + +[How] +- Do not change panel mode, if ASSR is disabled +- Just report and continue to perform eDP link training +with right settings further. + +Signed-off-by: Praful Swarnakar +Reviewed-by: Harry Wentland +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 15 +++++++-------- + 1 file changed, 7 insertions(+), 8 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +@@ -1813,14 +1813,13 @@ bool perform_link_training_with_retries( + if (panel_mode == DP_PANEL_MODE_EDP) { + struct cp_psp *cp_psp = &stream->ctx->cp_psp; + +- if (cp_psp && cp_psp->funcs.enable_assr) { +- if (!cp_psp->funcs.enable_assr(cp_psp->handle, link)) { +- /* since eDP implies ASSR on, change panel +- * mode to disable ASSR +- */ +- panel_mode = DP_PANEL_MODE_DEFAULT; +- } +- } ++ if (cp_psp && cp_psp->funcs.enable_assr) ++ /* ASSR is bound to fail with unsigned PSP ++ * verstage used during devlopment phase. ++ * Report and continue with eDP panel mode to ++ * perform eDP link training with right settings ++ */ ++ cp_psp->funcs.enable_assr(cp_psp->handle, link); + } + #endif + diff --git a/queue-5.14/drm-amd-display-initialize-backlight_ramping_override-to-false.patch b/queue-5.14/drm-amd-display-initialize-backlight_ramping_override-to-false.patch new file mode 100644 index 00000000000..f5cb0ea4217 --- /dev/null +++ b/queue-5.14/drm-amd-display-initialize-backlight_ramping_override-to-false.patch @@ -0,0 +1,37 @@ +From 467a51b69d0828887fb1b6719159a6b16da688f8 Mon Sep 17 00:00:00 2001 +From: Josip Pavic +Date: Fri, 17 Sep 2021 11:01:47 -0400 +Subject: drm/amd/display: initialize backlight_ramping_override to false + +From: Josip Pavic + +commit 467a51b69d0828887fb1b6719159a6b16da688f8 upstream. + +[Why] +Stack variable params.backlight_ramping_override is uninitialized, so it +contains junk data + +[How] +Initialize the variable to false + +Reviewed-by: Roman Li +Acked-by: Anson Jacob +Signed-off-by: Josip Pavic +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -1724,6 +1724,7 @@ static int dm_late_init(void *handle) + linear_lut[i] = 0xFFFF * i / 15; + + params.set = 0; ++ params.backlight_ramping_override = false; + params.backlight_ramping_start = 0xCCCC; + params.backlight_ramping_reduction = 0xCCCCCCCC; + params.backlight_lut_array_size = 16; diff --git a/queue-5.14/drm-amd-display-pass-pci-deviceid-into-dc.patch b/queue-5.14/drm-amd-display-pass-pci-deviceid-into-dc.patch new file mode 100644 index 00000000000..69508384b25 --- /dev/null +++ b/queue-5.14/drm-amd-display-pass-pci-deviceid-into-dc.patch @@ -0,0 +1,37 @@ +From d942856865c733ff60450de9691af796ad71d7bc Mon Sep 17 00:00:00 2001 +From: Charlene Liu +Date: Mon, 20 Sep 2021 14:30:02 -0400 +Subject: drm/amd/display: Pass PCI deviceid into DC + +From: Charlene Liu + +commit d942856865c733ff60450de9691af796ad71d7bc upstream. + +[why] +pci deviceid not passed to dal dc, without proper break, +dcn2.x falls into dcn3.x code path + +[how] +pass in pci deviceid, and break once dal_version initialized. + +Reviewed-by: Zhan Liu +Acked-by: Anson Jacob +Signed-off-by: Charlene Liu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -1117,6 +1117,7 @@ static int amdgpu_dm_init(struct amdgpu_ + + init_data.asic_id.pci_revision_id = adev->pdev->revision; + init_data.asic_id.hw_internal_rev = adev->external_rev_id; ++ init_data.asic_id.chip_id = adev->pdev->device; + + init_data.asic_id.vram_width = adev->gmc.vram_width; + /* TODO: initialize init_data.asic_id.vram_type here!!!! */ diff --git a/queue-5.14/drm-amdgpu-check-tiling-flags-when-creating-fb-on-gfx8.patch b/queue-5.14/drm-amdgpu-check-tiling-flags-when-creating-fb-on-gfx8.patch new file mode 100644 index 00000000000..c074c7c3281 --- /dev/null +++ b/queue-5.14/drm-amdgpu-check-tiling-flags-when-creating-fb-on-gfx8.patch @@ -0,0 +1,95 @@ +From 98122e63a7ecc08c4172a17d97a06ef5536eb268 Mon Sep 17 00:00:00 2001 +From: Simon Ser +Date: Mon, 27 Sep 2021 15:08:44 +0000 +Subject: drm/amdgpu: check tiling flags when creating FB on GFX8- +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Simon Ser + +commit 98122e63a7ecc08c4172a17d97a06ef5536eb268 upstream. + +On GFX9+, format modifiers are always enabled and ensure the +frame-buffers can be scanned out at ADDFB2 time. + +On GFX8-, format modifiers are not supported and no other check +is performed. This means ADDFB2 IOCTLs will succeed even if the +tiling isn't supported for scan-out, and will result in garbage +displayed on screen [1]. + +Fix this by adding a check for tiling flags for GFX8 and older. +The check is taken from radeonsi in Mesa (see how is_displayable +is populated in gfx6_compute_surface). + +Changes in v2: use drm_WARN_ONCE instead of drm_WARN (Michel) + +[1]: https://github.com/swaywm/wlroots/issues/3185 + +Signed-off-by: Simon Ser +Acked-by: Michel Dänzer +Cc: Alex Deucher +Cc: Harry Wentland +Cc: Nicholas Kazlauskas +Cc: Bas Nieuwenhuizen +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 31 ++++++++++++++++++++++++++++ + 1 file changed, 31 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +@@ -837,6 +837,28 @@ static int convert_tiling_flags_to_modif + return 0; + } + ++/* Mirrors the is_displayable check in radeonsi's gfx6_compute_surface */ ++static int check_tiling_flags_gfx6(struct amdgpu_framebuffer *afb) ++{ ++ u64 micro_tile_mode; ++ ++ /* Zero swizzle mode means linear */ ++ if (AMDGPU_TILING_GET(afb->tiling_flags, SWIZZLE_MODE) == 0) ++ return 0; ++ ++ micro_tile_mode = AMDGPU_TILING_GET(afb->tiling_flags, MICRO_TILE_MODE); ++ switch (micro_tile_mode) { ++ case 0: /* DISPLAY */ ++ case 3: /* RENDER */ ++ return 0; ++ default: ++ drm_dbg_kms(afb->base.dev, ++ "Micro tile mode %llu not supported for scanout\n", ++ micro_tile_mode); ++ return -EINVAL; ++ } ++} ++ + static void get_block_dimensions(unsigned int block_log2, unsigned int cpp, + unsigned int *width, unsigned int *height) + { +@@ -1103,6 +1125,7 @@ int amdgpu_display_framebuffer_init(stru + const struct drm_mode_fb_cmd2 *mode_cmd, + struct drm_gem_object *obj) + { ++ struct amdgpu_device *adev = drm_to_adev(dev); + int ret, i; + + /* +@@ -1122,6 +1145,14 @@ int amdgpu_display_framebuffer_init(stru + if (ret) + return ret; + ++ if (!dev->mode_config.allow_fb_modifiers) { ++ drm_WARN_ONCE(dev, adev->family >= AMDGPU_FAMILY_AI, ++ "GFX9+ requires FB check based on format modifier\n"); ++ ret = check_tiling_flags_gfx6(rfb); ++ if (ret) ++ return ret; ++ } ++ + if (dev->mode_config.allow_fb_modifiers && + !(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) { + ret = convert_tiling_flags_to_modifier(rfb); diff --git a/queue-5.14/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch b/queue-5.14/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch new file mode 100644 index 00000000000..d18832f96c0 --- /dev/null +++ b/queue-5.14/drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch @@ -0,0 +1,32 @@ +From 9f52c25f59b504a29dda42d83ac1e24d2af535d4 Mon Sep 17 00:00:00 2001 +From: Hawking Zhang +Date: Sun, 26 Sep 2021 22:19:35 +0800 +Subject: drm/amdgpu: correct initial cp_hqd_quantum for gfx9 + +From: Hawking Zhang + +commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream. + +didn't read the value of mmCP_HQD_QUANTUM from correct +register offset + +Signed-off-by: Hawking Zhang +Reviewed-by: Le Ma +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +@@ -3598,7 +3598,7 @@ static int gfx_v9_0_mqd_init(struct amdg + + /* set static priority for a queue/ring */ + gfx_v9_0_mqd_set_priority(ring, mqd); +- mqd->cp_hqd_quantum = RREG32(mmCP_HQD_QUANTUM); ++ mqd->cp_hqd_quantum = RREG32_SOC15(GC, 0, mmCP_HQD_QUANTUM); + + /* map_queues packet doesn't need activate the queue, + * so only kiq need set this field. diff --git a/queue-5.14/drm-amdgpu-force-exit-gfxoff-on-sdma-resume-for-rmb-s0ix.patch b/queue-5.14/drm-amdgpu-force-exit-gfxoff-on-sdma-resume-for-rmb-s0ix.patch new file mode 100644 index 00000000000..15e3df67bce --- /dev/null +++ b/queue-5.14/drm-amdgpu-force-exit-gfxoff-on-sdma-resume-for-rmb-s0ix.patch @@ -0,0 +1,47 @@ +From 26db706a6d77b9e184feb11725e97e53b7a89519 Mon Sep 17 00:00:00 2001 +From: Prike Liang +Date: Wed, 25 Aug 2021 13:36:38 +0800 +Subject: drm/amdgpu: force exit gfxoff on sdma resume for rmb s0ix + +From: Prike Liang + +commit 26db706a6d77b9e184feb11725e97e53b7a89519 upstream. + +In the s2idle stress test sdma resume fail occasionally,in the +failed case GPU is in the gfxoff state.This issue may introduce +by firmware miss handle doorbell S/R and now temporary fix the issue +by forcing exit gfxoff for sdma resume. + +Signed-off-by: Prike Liang +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c ++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c +@@ -883,6 +883,12 @@ static int sdma_v5_2_start(struct amdgpu + msleep(1000); + } + ++ /* TODO: check whether can submit a doorbell request to raise ++ * a doorbell fence to exit gfxoff. ++ */ ++ if (adev->in_s0ix) ++ amdgpu_gfx_off_ctrl(adev, false); ++ + sdma_v5_2_soft_reset(adev); + /* unhalt the MEs */ + sdma_v5_2_enable(adev, true); +@@ -891,6 +897,8 @@ static int sdma_v5_2_start(struct amdgpu + + /* start the gfx rings and rlc compute queues */ + r = sdma_v5_2_gfx_resume(adev); ++ if (adev->in_s0ix) ++ amdgpu_gfx_off_ctrl(adev, true); + if (r) + return r; + r = sdma_v5_2_rlc_resume(adev); diff --git a/queue-5.14/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch b/queue-5.14/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch new file mode 100644 index 00000000000..6e4eb9c8744 --- /dev/null +++ b/queue-5.14/kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch @@ -0,0 +1,85 @@ +From 8d68bad6d869fae8f4d50ab6423538dec7da72d1 Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Tue, 7 Sep 2021 18:35:30 +0200 +Subject: KVM: nVMX: Filter out all unsupported controls when eVMCS was activated + +From: Vitaly Kuznetsov + +commit 8d68bad6d869fae8f4d50ab6423538dec7da72d1 upstream. + +Windows Server 2022 with Hyper-V role enabled failed to boot on KVM when +enlightened VMCS is advertised. Debugging revealed there are two exposed +secondary controls it is not happy with: SECONDARY_EXEC_ENABLE_VMFUNC and +SECONDARY_EXEC_SHADOW_VMCS. These controls are known to be unsupported, +as there are no corresponding fields in eVMCSv1 (see the comment above +EVMCS1_UNSUPPORTED_2NDEXEC definition). + +Previously, commit 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls +sanitization out of nested_enable_evmcs()") introduced the required +filtering mechanism for VMX MSRs but for some reason put only known +to be problematic (and not full EVMCS1_UNSUPPORTED_* lists) controls +there. + +Note, Windows Server 2022 seems to have gained some sanity check for VMX +MSRs: it doesn't even try to launch a guest when there's something it +doesn't like, nested_evmcs_check_controls() mechanism can't catch the +problem. + +Let's be bold this time and instead of playing whack-a-mole just filter out +all unsupported controls from VMX MSRs. + +Fixes: 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()") +Signed-off-by: Vitaly Kuznetsov +Message-Id: <20210907163530.110066-1-vkuznets@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/evmcs.c | 12 +++++++++--- + arch/x86/kvm/vmx/vmx.c | 9 +++++---- + 2 files changed, 14 insertions(+), 7 deletions(-) + +--- a/arch/x86/kvm/vmx/evmcs.c ++++ b/arch/x86/kvm/vmx/evmcs.c +@@ -354,14 +354,20 @@ void nested_evmcs_filter_control_msr(u32 + switch (msr_index) { + case MSR_IA32_VMX_EXIT_CTLS: + case MSR_IA32_VMX_TRUE_EXIT_CTLS: +- ctl_high &= ~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL; ++ ctl_high &= ~EVMCS1_UNSUPPORTED_VMEXIT_CTRL; + break; + case MSR_IA32_VMX_ENTRY_CTLS: + case MSR_IA32_VMX_TRUE_ENTRY_CTLS: +- ctl_high &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL; ++ ctl_high &= ~EVMCS1_UNSUPPORTED_VMENTRY_CTRL; + break; + case MSR_IA32_VMX_PROCBASED_CTLS2: +- ctl_high &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES; ++ ctl_high &= ~EVMCS1_UNSUPPORTED_2NDEXEC; ++ break; ++ case MSR_IA32_VMX_PINBASED_CTLS: ++ ctl_high &= ~EVMCS1_UNSUPPORTED_PINCTRL; ++ break; ++ case MSR_IA32_VMX_VMFUNC: ++ ctl_low &= ~EVMCS1_UNSUPPORTED_VMFUNC; + break; + } + +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -1840,10 +1840,11 @@ static int vmx_get_msr(struct kvm_vcpu * + &msr_info->data)) + return 1; + /* +- * Enlightened VMCS v1 doesn't have certain fields, but buggy +- * Hyper-V versions are still trying to use corresponding +- * features when they are exposed. Filter out the essential +- * minimum. ++ * Enlightened VMCS v1 doesn't have certain VMCS fields but ++ * instead of just ignoring the features, different Hyper-V ++ * versions are either trying to use them and fail or do some ++ * sanity checking and refuse to boot. Filter all unsupported ++ * features out. + */ + if (!msr_info->host_initiated && + vmx->nested.enlightened_vmcs_enabled) diff --git a/queue-5.14/kvm-nvmx-fix-nested-bus-lock-vm-exit.patch b/queue-5.14/kvm-nvmx-fix-nested-bus-lock-vm-exit.patch new file mode 100644 index 00000000000..11d1d563d20 --- /dev/null +++ b/queue-5.14/kvm-nvmx-fix-nested-bus-lock-vm-exit.patch @@ -0,0 +1,40 @@ +From 24a996ade34d00deef5dee2c33aacd8fda91ec31 Mon Sep 17 00:00:00 2001 +From: Chenyi Qiang +Date: Tue, 14 Sep 2021 17:50:41 +0800 +Subject: KVM: nVMX: Fix nested bus lock VM exit + +From: Chenyi Qiang + +commit 24a996ade34d00deef5dee2c33aacd8fda91ec31 upstream. + +Nested bus lock VM exits are not supported yet. If L2 triggers bus lock +VM exit, it will be directed to L1 VMM, which would cause unexpected +behavior. Therefore, handle L2's bus lock VM exits in L0 directly. + +Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit") +Signed-off-by: Chenyi Qiang +Reviewed-by: Sean Christopherson +Reviewed-by: Xiaoyao Li +Message-Id: <20210914095041.29764-1-chenyi.qiang@intel.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/nested.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -5898,6 +5898,12 @@ static bool nested_vmx_l0_wants_exit(str + case EXIT_REASON_VMFUNC: + /* VM functions are emulated through L2->L0 vmexits. */ + return true; ++ case EXIT_REASON_BUS_LOCK: ++ /* ++ * At present, bus lock VM exit is never exposed to L1. ++ * Handle L2's bus locks in L0 directly. ++ */ ++ return true; + default: + break; + } diff --git a/queue-5.14/kvm-sev-acquire-vcpu-mutex-when-updating-vmsa.patch b/queue-5.14/kvm-sev-acquire-vcpu-mutex-when-updating-vmsa.patch new file mode 100644 index 00000000000..5c90fb65458 --- /dev/null +++ b/queue-5.14/kvm-sev-acquire-vcpu-mutex-when-updating-vmsa.patch @@ -0,0 +1,109 @@ +From bb18a677746543e7f5eeb478129c92cedb0f9658 Mon Sep 17 00:00:00 2001 +From: Peter Gonda +Date: Wed, 15 Sep 2021 10:17:55 -0700 +Subject: KVM: SEV: Acquire vcpu mutex when updating VMSA + +From: Peter Gonda + +commit bb18a677746543e7f5eeb478129c92cedb0f9658 upstream. + +The update-VMSA ioctl touches data stored in struct kvm_vcpu, and +therefore should not be performed concurrently with any VCPU ioctl +that might cause KVM or the processor to use the same data. + +Adds vcpu mutex guard to the VMSA updating code. Refactors out +__sev_launch_update_vmsa() function to deal with per vCPU parts +of sev_launch_update_vmsa(). + +Fixes: ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest") +Signed-off-by: Peter Gonda +Cc: Marc Orr +Cc: Paolo Bonzini +Cc: Sean Christopherson +Cc: Brijesh Singh +Cc: kvm@vger.kernel.org +Cc: stable@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Message-Id: <20210915171755.3773766-1-pgonda@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 53 +++++++++++++++++++++++++++---------------------- + 1 file changed, 30 insertions(+), 23 deletions(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -596,43 +596,50 @@ static int sev_es_sync_vmsa(struct vcpu_ + return 0; + } + +-static int sev_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp) ++static int __sev_launch_update_vmsa(struct kvm *kvm, struct kvm_vcpu *vcpu, ++ int *error) + { +- struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; + struct sev_data_launch_update_vmsa vmsa; ++ struct vcpu_svm *svm = to_svm(vcpu); ++ int ret; ++ ++ /* Perform some pre-encryption checks against the VMSA */ ++ ret = sev_es_sync_vmsa(svm); ++ if (ret) ++ return ret; ++ ++ /* ++ * The LAUNCH_UPDATE_VMSA command will perform in-place encryption of ++ * the VMSA memory content (i.e it will write the same memory region ++ * with the guest's key), so invalidate it first. ++ */ ++ clflush_cache_range(svm->vmsa, PAGE_SIZE); ++ ++ vmsa.reserved = 0; ++ vmsa.handle = to_kvm_svm(kvm)->sev_info.handle; ++ vmsa.address = __sme_pa(svm->vmsa); ++ vmsa.len = PAGE_SIZE; ++ return sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_VMSA, &vmsa, error); ++} ++ ++static int sev_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp) ++{ + struct kvm_vcpu *vcpu; + int i, ret; + + if (!sev_es_guest(kvm)) + return -ENOTTY; + +- vmsa.reserved = 0; +- + kvm_for_each_vcpu(i, vcpu, kvm) { +- struct vcpu_svm *svm = to_svm(vcpu); +- +- /* Perform some pre-encryption checks against the VMSA */ +- ret = sev_es_sync_vmsa(svm); ++ ret = mutex_lock_killable(&vcpu->mutex); + if (ret) + return ret; + +- /* +- * The LAUNCH_UPDATE_VMSA command will perform in-place +- * encryption of the VMSA memory content (i.e it will write +- * the same memory region with the guest's key), so invalidate +- * it first. +- */ +- clflush_cache_range(svm->vmsa, PAGE_SIZE); +- +- vmsa.handle = sev->handle; +- vmsa.address = __sme_pa(svm->vmsa); +- vmsa.len = PAGE_SIZE; +- ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_VMSA, &vmsa, +- &argp->error); ++ ret = __sev_launch_update_vmsa(kvm, vcpu, &argp->error); ++ ++ mutex_unlock(&vcpu->mutex); + if (ret) + return ret; +- +- svm->vcpu.arch.guest_state_protected = true; + } + + return 0; diff --git a/queue-5.14/kvm-sev-allow-some-commands-for-mirror-vm.patch b/queue-5.14/kvm-sev-allow-some-commands-for-mirror-vm.patch new file mode 100644 index 00000000000..779a665bee3 --- /dev/null +++ b/queue-5.14/kvm-sev-allow-some-commands-for-mirror-vm.patch @@ -0,0 +1,69 @@ +From 5b92b6ca92b65bef811048c481e4446f4828500a Mon Sep 17 00:00:00 2001 +From: Peter Gonda +Date: Tue, 21 Sep 2021 08:03:45 -0700 +Subject: KVM: SEV: Allow some commands for mirror VM + +From: Peter Gonda + +commit 5b92b6ca92b65bef811048c481e4446f4828500a upstream. + +A mirrored SEV-ES VM will need to call KVM_SEV_LAUNCH_UPDATE_VMSA to +setup its vCPUs and have them measured, and their VMSAs encrypted. Without +this change, it is impossible to have mirror VMs as part of SEV-ES VMs. + +Also allow the guest status check and debugging commands since they do +not change any guest state. + +Signed-off-by: Peter Gonda +Cc: Marc Orr +Cc: Nathan Tempelman +Cc: Paolo Bonzini +Cc: Sean Christopherson +Cc: Steve Rutherford +Cc: Brijesh Singh +Cc: kvm@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org +Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context", 2021-04-21) +Message-Id: <20210921150345.2221634-3-pgonda@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 19 +++++++++++++++++-- + 1 file changed, 17 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -1509,6 +1509,20 @@ static int sev_receive_finish(struct kvm + return sev_issue_cmd(kvm, SEV_CMD_RECEIVE_FINISH, &data, &argp->error); + } + ++static bool cmd_allowed_from_miror(u32 cmd_id) ++{ ++ /* ++ * Allow mirrors VM to call KVM_SEV_LAUNCH_UPDATE_VMSA to enable SEV-ES ++ * active mirror VMs. Also allow the debugging and status commands. ++ */ ++ if (cmd_id == KVM_SEV_LAUNCH_UPDATE_VMSA || ++ cmd_id == KVM_SEV_GUEST_STATUS || cmd_id == KVM_SEV_DBG_DECRYPT || ++ cmd_id == KVM_SEV_DBG_ENCRYPT) ++ return true; ++ ++ return false; ++} ++ + int svm_mem_enc_op(struct kvm *kvm, void __user *argp) + { + struct kvm_sev_cmd sev_cmd; +@@ -1525,8 +1539,9 @@ int svm_mem_enc_op(struct kvm *kvm, void + + mutex_lock(&kvm->lock); + +- /* enc_context_owner handles all memory enc operations */ +- if (is_mirroring_enc_context(kvm)) { ++ /* Only the enc_context_owner handles some memory enc operations. */ ++ if (is_mirroring_enc_context(kvm) && ++ !cmd_allowed_from_miror(sev_cmd.id)) { + r = -EINVAL; + goto out; + } diff --git a/queue-5.14/kvm-sev-pin-guest-memory-for-write-for-receive_update_data.patch b/queue-5.14/kvm-sev-pin-guest-memory-for-write-for-receive_update_data.patch new file mode 100644 index 00000000000..3c0aa51b361 --- /dev/null +++ b/queue-5.14/kvm-sev-pin-guest-memory-for-write-for-receive_update_data.patch @@ -0,0 +1,42 @@ +From 50c038018d6be20361e8a2890262746a4ac5b11f Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 14 Sep 2021 14:09:50 -0700 +Subject: KVM: SEV: Pin guest memory for write for RECEIVE_UPDATE_DATA + +From: Sean Christopherson + +commit 50c038018d6be20361e8a2890262746a4ac5b11f upstream. + +Require the target guest page to be writable when pinning memory for +RECEIVE_UPDATE_DATA. Per the SEV API, the PSP writes to guest memory: + + The result is then encrypted with GCTX.VEK and written to the memory + pointed to by GUEST_PADDR field. + +Fixes: 15fb7de1a7f5 ("KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command") +Cc: stable@vger.kernel.org +Cc: Peter Gonda +Cc: Marc Orr +Cc: Tom Lendacky +Cc: Brijesh Singh +Signed-off-by: Sean Christopherson +Message-Id: <20210914210951.2994260-2-seanjc@google.com> +Reviewed-by: Brijesh Singh +Reviewed-by: Peter Gonda +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -1465,7 +1465,7 @@ static int sev_receive_update_data(struc + + /* Pin guest memory */ + guest_page = sev_pin_memory(kvm, params.guest_uaddr & PAGE_MASK, +- PAGE_SIZE, &n, 0); ++ PAGE_SIZE, &n, 1); + if (IS_ERR(guest_page)) { + ret = PTR_ERR(guest_page); + goto e_free_trans; diff --git a/queue-5.14/kvm-sev-update-svm_vm_copy_asid_from-for-sev-es.patch b/queue-5.14/kvm-sev-update-svm_vm_copy_asid_from-for-sev-es.patch new file mode 100644 index 00000000000..f1f1d2aba9a --- /dev/null +++ b/queue-5.14/kvm-sev-update-svm_vm_copy_asid_from-for-sev-es.patch @@ -0,0 +1,72 @@ +From f43c887cb7cb5b66c4167d40a4209027f5fdb5ce Mon Sep 17 00:00:00 2001 +From: Peter Gonda +Date: Tue, 21 Sep 2021 08:03:44 -0700 +Subject: KVM: SEV: Update svm_vm_copy_asid_from for SEV-ES + +From: Peter Gonda + +commit f43c887cb7cb5b66c4167d40a4209027f5fdb5ce upstream. + +For mirroring SEV-ES the mirror VM will need more then just the ASID. +The FD and the handle are required to all the mirror to call psp +commands. The mirror VM will need to call KVM_SEV_LAUNCH_UPDATE_VMSA to +setup its vCPUs' VMSAs for SEV-ES. + +Signed-off-by: Peter Gonda +Cc: Marc Orr +Cc: Nathan Tempelman +Cc: Paolo Bonzini +Cc: Sean Christopherson +Cc: Steve Rutherford +Cc: Brijesh Singh +Cc: kvm@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org +Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context", 2021-04-21) +Message-Id: <20210921150345.2221634-2-pgonda@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -1716,8 +1716,7 @@ int svm_vm_copy_asid_from(struct kvm *kv + { + struct file *source_kvm_file; + struct kvm *source_kvm; +- struct kvm_sev_info *mirror_sev; +- unsigned int asid; ++ struct kvm_sev_info source_sev, *mirror_sev; + int ret; + + source_kvm_file = fget(source_fd); +@@ -1740,7 +1739,8 @@ int svm_vm_copy_asid_from(struct kvm *kv + goto e_source_unlock; + } + +- asid = to_kvm_svm(source_kvm)->sev_info.asid; ++ memcpy(&source_sev, &to_kvm_svm(source_kvm)->sev_info, ++ sizeof(source_sev)); + + /* + * The mirror kvm holds an enc_context_owner ref so its asid can't +@@ -1760,8 +1760,16 @@ int svm_vm_copy_asid_from(struct kvm *kv + /* Set enc_context_owner and copy its encryption context over */ + mirror_sev = &to_kvm_svm(kvm)->sev_info; + mirror_sev->enc_context_owner = source_kvm; +- mirror_sev->asid = asid; + mirror_sev->active = true; ++ mirror_sev->asid = source_sev.asid; ++ mirror_sev->fd = source_sev.fd; ++ mirror_sev->es_active = source_sev.es_active; ++ mirror_sev->handle = source_sev.handle; ++ /* ++ * Do not copy ap_jump_table. Since the mirror does not share the same ++ * KVM contexts as the original, and they may have different ++ * memory-views. ++ */ + + mutex_unlock(&kvm->lock); + return 0; diff --git a/queue-5.14/kvm-svm-fix-missing-sev_decommission-in-sev_receive_start.patch b/queue-5.14/kvm-svm-fix-missing-sev_decommission-in-sev_receive_start.patch new file mode 100644 index 00000000000..a0092ec754e --- /dev/null +++ b/queue-5.14/kvm-svm-fix-missing-sev_decommission-in-sev_receive_start.patch @@ -0,0 +1,61 @@ +From f1815e0aa770f2127c5df31eb5c2f0e37b60fa77 Mon Sep 17 00:00:00 2001 +From: Mingwei Zhang +Date: Sun, 12 Sep 2021 18:18:15 +0000 +Subject: KVM: SVM: fix missing sev_decommission in sev_receive_start + +From: Mingwei Zhang + +commit f1815e0aa770f2127c5df31eb5c2f0e37b60fa77 upstream. + +DECOMMISSION the current SEV context if binding an ASID fails after +RECEIVE_START. Per AMD's SEV API, RECEIVE_START generates a new guest +context and thus needs to be paired with DECOMMISSION: + + The RECEIVE_START command is the only command other than the LAUNCH_START + command that generates a new guest context and guest handle. + +The missing DECOMMISSION can result in subsequent SEV launch failures, +as the firmware leaks memory and might not able to allocate more SEV +guest contexts in the future. + +Note, LAUNCH_START suffered the same bug, but was previously fixed by +commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID +binding fails"). + +Cc: Alper Gun +Cc: Borislav Petkov +Cc: Brijesh Singh +Cc: David Rienjes +Cc: Marc Orr +Cc: John Allen +Cc: Peter Gonda +Cc: Sean Christopherson +Cc: Tom Lendacky +Cc: Vipin Sharma +Cc: stable@vger.kernel.org +Reviewed-by: Marc Orr +Acked-by: Brijesh Singh +Fixes: af43cbbf954b ("KVM: SVM: Add support for KVM_SEV_RECEIVE_START command") +Signed-off-by: Mingwei Zhang +Reviewed-by: Sean Christopherson +Message-Id: <20210912181815.3899316-1-mizhang@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -1405,8 +1405,10 @@ static int sev_receive_start(struct kvm + + /* Bind ASID to this guest */ + ret = sev_bind_asid(kvm, start.handle, error); +- if (ret) ++ if (ret) { ++ sev_decommission(start.handle); + goto e_free_session; ++ } + + params.handle = start.handle; + if (copy_to_user((void __user *)(uintptr_t)argp->data, diff --git a/queue-5.14/kvm-vmx-fix-a-tsx_ctrl_cpuid_clear-field-mask-issue.patch b/queue-5.14/kvm-vmx-fix-a-tsx_ctrl_cpuid_clear-field-mask-issue.patch new file mode 100644 index 00000000000..f11950ee89e --- /dev/null +++ b/queue-5.14/kvm-vmx-fix-a-tsx_ctrl_cpuid_clear-field-mask-issue.patch @@ -0,0 +1,41 @@ +From 5c49d1850ddd3240d20dc40b01f593e35a184f38 Mon Sep 17 00:00:00 2001 +From: Zhenzhong Duan +Date: Sun, 26 Sep 2021 09:55:45 +0800 +Subject: KVM: VMX: Fix a TSX_CTRL_CPUID_CLEAR field mask issue + +From: Zhenzhong Duan + +commit 5c49d1850ddd3240d20dc40b01f593e35a184f38 upstream. + +When updating the host's mask for its MSR_IA32_TSX_CTRL user return entry, +clear the mask in the found uret MSR instead of vmx->guest_uret_msrs[i]. +Modifying guest_uret_msrs directly is completely broken as 'i' does not +point at the MSR_IA32_TSX_CTRL entry. In fact, it's guaranteed to be an +out-of-bounds accesses as is always set to kvm_nr_uret_msrs in a prior +loop. By sheer dumb luck, the fallout is limited to "only" failing to +preserve the host's TSX_CTRL_CPUID_CLEAR. The out-of-bounds access is +benign as it's guaranteed to clear a bit in a guest MSR value, which are +always zero at vCPU creation on both x86-64 and i386. + +Cc: stable@vger.kernel.org +Fixes: 8ea8b8d6f869 ("KVM: VMX: Use common x86's uret MSR list as the one true list") +Signed-off-by: Zhenzhong Duan +Reviewed-by: Sean Christopherson +Message-Id: <20210926015545.281083-1-zhenzhong.duan@intel.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/vmx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -6816,7 +6816,7 @@ static int vmx_create_vcpu(struct kvm_vc + */ + tsx_ctrl = vmx_find_uret_msr(vmx, MSR_IA32_TSX_CTRL); + if (tsx_ctrl) +- vmx->guest_uret_msrs[i].mask = ~(u64)TSX_CTRL_CPUID_CLEAR; ++ tsx_ctrl->mask = ~(u64)TSX_CTRL_CPUID_CLEAR; + } + + err = alloc_loaded_vmcs(&vmx->vmcs01); diff --git a/queue-5.14/kvm-x86-clear-kvm-s-cached-guest-cr3-at-reset-init.patch b/queue-5.14/kvm-x86-clear-kvm-s-cached-guest-cr3-at-reset-init.patch new file mode 100644 index 00000000000..830b0b79c33 --- /dev/null +++ b/queue-5.14/kvm-x86-clear-kvm-s-cached-guest-cr3-at-reset-init.patch @@ -0,0 +1,37 @@ +From 03a6e84069d1870f5b3d360e64cb330b66f76dee Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 20 Sep 2021 17:02:55 -0700 +Subject: KVM: x86: Clear KVM's cached guest CR3 at RESET/INIT + +From: Sean Christopherson + +commit 03a6e84069d1870f5b3d360e64cb330b66f76dee upstream. + +Explicitly zero the guest's CR3 and mark it available+dirty at RESET/INIT. +Per Intel's SDM and AMD's APM, CR3 is zeroed at both RESET and INIT. For +RESET, this is a nop as vcpu is zero-allocated. For INIT, the bug has +likely escaped notice because no firmware/kernel puts its page tables root +at PA=0, let alone relies on INIT to get the desired CR3 for such page +tables. + +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210921000303.400537-3-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/x86.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -10873,6 +10873,9 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcp + + static_call(kvm_x86_vcpu_reset)(vcpu, init_event); + ++ vcpu->arch.cr3 = 0; ++ kvm_register_mark_dirty(vcpu, VCPU_EXREG_CR3); ++ + /* + * Reset the MMU context if paging was enabled prior to INIT (which is + * implied if CR0.PG=1 as CR0 will be '0' prior to RESET). Unlike the diff --git a/queue-5.14/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch b/queue-5.14/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch new file mode 100644 index 00000000000..4ad3d30ae9d --- /dev/null +++ b/queue-5.14/kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch @@ -0,0 +1,91 @@ +From 2f9b68f57c6278c322793a06063181deded0ad69 Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Fri, 27 Aug 2021 11:25:14 +0200 +Subject: KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect() + +From: Vitaly Kuznetsov + +commit 2f9b68f57c6278c322793a06063181deded0ad69 upstream. + +KASAN reports the following issue: + + BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm] + Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798 + + CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- --- + Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020 + Call Trace: + dump_stack+0xa5/0xe6 + print_address_description.constprop.0+0x18/0x130 + ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] + __kasan_report.cold+0x7f/0x114 + ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] + kasan_report+0x38/0x50 + kasan_check_range+0xf5/0x1d0 + kvm_make_vcpus_request_mask+0x174/0x440 [kvm] + kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm] + ? kvm_arch_exit+0x110/0x110 [kvm] + ? sched_clock+0x5/0x10 + ioapic_write_indirect+0x59f/0x9e0 [kvm] + ? static_obj+0xc0/0xc0 + ? __lock_acquired+0x1d2/0x8c0 + ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] + +The problem appears to be that 'vcpu_bitmap' is allocated as a single long +on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear +the lower 16 bits of it with bitmap_zero() for no particular reason (my +guess would be that 'bitmap' and 'vcpu_bitmap' variables in +kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed +16-bit long, the later should accommodate all possible vCPUs). + +Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs") +Fixes: 9a2ae9f6b6bb ("KVM: x86: Zero the IOAPIC scan request dest vCPUs bitmap") +Reported-by: Dr. David Alan Gilbert +Signed-off-by: Vitaly Kuznetsov +Reviewed-by: Maxim Levitsky +Reviewed-by: Sean Christopherson +Message-Id: <20210827092516.1027264-7-vkuznets@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/ioapic.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/arch/x86/kvm/ioapic.c ++++ b/arch/x86/kvm/ioapic.c +@@ -319,8 +319,8 @@ static void ioapic_write_indirect(struct + unsigned index; + bool mask_before, mask_after; + union kvm_ioapic_redirect_entry *e; +- unsigned long vcpu_bitmap; + int old_remote_irr, old_delivery_status, old_dest_id, old_dest_mode; ++ DECLARE_BITMAP(vcpu_bitmap, KVM_MAX_VCPUS); + + switch (ioapic->ioregsel) { + case IOAPIC_REG_VERSION: +@@ -384,9 +384,9 @@ static void ioapic_write_indirect(struct + irq.shorthand = APIC_DEST_NOSHORT; + irq.dest_id = e->fields.dest_id; + irq.msi_redir_hint = false; +- bitmap_zero(&vcpu_bitmap, 16); ++ bitmap_zero(vcpu_bitmap, KVM_MAX_VCPUS); + kvm_bitmap_or_dest_vcpus(ioapic->kvm, &irq, +- &vcpu_bitmap); ++ vcpu_bitmap); + if (old_dest_mode != e->fields.dest_mode || + old_dest_id != e->fields.dest_id) { + /* +@@ -399,10 +399,10 @@ static void ioapic_write_indirect(struct + kvm_lapic_irq_dest_mode( + !!e->fields.dest_mode); + kvm_bitmap_or_dest_vcpus(ioapic->kvm, &irq, +- &vcpu_bitmap); ++ vcpu_bitmap); + } + kvm_make_scan_ioapic_request_mask(ioapic->kvm, +- &vcpu_bitmap); ++ vcpu_bitmap); + } else { + kvm_make_scan_ioapic_request(ioapic->kvm); + } diff --git a/queue-5.14/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch b/queue-5.14/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch new file mode 100644 index 00000000000..d6ba7bd64df --- /dev/null +++ b/queue-5.14/kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch @@ -0,0 +1,34 @@ +From faf6b755629627f19feafa75b32e81cd7738f12d Mon Sep 17 00:00:00 2001 +From: Maxim Levitsky +Date: Tue, 14 Sep 2021 18:48:16 +0300 +Subject: KVM: x86: nSVM: don't copy virt_ext from vmcb12 + +From: Maxim Levitsky + +commit faf6b755629627f19feafa75b32e81cd7738f12d upstream. + +These field correspond to features that we don't expose yet to L2 + +While currently there are no CVE worthy features in this field, +if AMD adds more features to this field, that could allow guest +escapes similar to CVE-2021-3653 and CVE-2021-3656. + +Signed-off-by: Maxim Levitsky +Message-Id: <20210914154825.104886-6-mlevitsk@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -545,7 +545,6 @@ static void nested_vmcb02_prepare_contro + (svm->nested.ctl.int_ctl & int_ctl_vmcb12_bits) | + (svm->vmcb01.ptr->control.int_ctl & int_ctl_vmcb01_bits); + +- svm->vmcb->control.virt_ext = svm->nested.ctl.virt_ext; + svm->vmcb->control.int_vector = svm->nested.ctl.int_vector; + svm->vmcb->control.int_state = svm->nested.ctl.int_state; + svm->vmcb->control.event_inj = svm->nested.ctl.event_inj; diff --git a/queue-5.14/kvm-x86-swap-order-of-cpuid-entry-index-vs.-significant-flag-checks.patch b/queue-5.14/kvm-x86-swap-order-of-cpuid-entry-index-vs.-significant-flag-checks.patch new file mode 100644 index 00000000000..d12d5d0657c --- /dev/null +++ b/queue-5.14/kvm-x86-swap-order-of-cpuid-entry-index-vs.-significant-flag-checks.patch @@ -0,0 +1,80 @@ +From e8a747d0884e554a8c1872da6c8f680a4f893c6d Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 29 Sep 2021 15:24:25 -0700 +Subject: KVM: x86: Swap order of CPUID entry "index" vs. "significant flag" checks + +From: Sean Christopherson + +commit e8a747d0884e554a8c1872da6c8f680a4f893c6d upstream. + +Check whether a CPUID entry's index is significant before checking for a +matching index to hack-a-fix an undefined behavior bug due to consuming +uninitialized data. RESET/INIT emulation uses kvm_cpuid() to retrieve +CPUID.0x1, which does _not_ have a significant index, and fails to +initialize the dummy variable that doubles as EBX/ECX/EDX output _and_ +ECX, a.k.a. index, input. + +Practically speaking, it's _extremely_ unlikely any compiler will yield +code that causes problems, as the compiler would need to inline the +kvm_cpuid() call to detect the uninitialized data, and intentionally hose +the kernel, e.g. insert ud2, instead of simply ignoring the result of +the index comparison. + +Although the sketchy "dummy" pattern was introduced in SVM by commit +66f7b72e1171 ("KVM: x86: Make register state after reset conform to +specification"), it wasn't actually broken until commit 7ff6c0350315 +("KVM: x86: Remove stateful CPUID handling") arbitrarily swapped the +order of operations such that "index" was checked before the significant +flag. + +Avoid consuming uninitialized data by reverting to checking the flag +before the index purely so that the fix can be easily backported; the +offending RESET/INIT code has been refactored, moved, and consolidated +from vendor code to common x86 since the bug was introduced. A future +patch will directly address the bad RESET/INIT behavior. + +The undefined behavior was detected by syzbot + KernelMemorySanitizer. + + BUG: KMSAN: uninit-value in cpuid_entry2_find arch/x86/kvm/cpuid.c:68 + BUG: KMSAN: uninit-value in kvm_find_cpuid_entry arch/x86/kvm/cpuid.c:1103 + BUG: KMSAN: uninit-value in kvm_cpuid+0x456/0x28f0 arch/x86/kvm/cpuid.c:1183 + cpuid_entry2_find arch/x86/kvm/cpuid.c:68 [inline] + kvm_find_cpuid_entry arch/x86/kvm/cpuid.c:1103 [inline] + kvm_cpuid+0x456/0x28f0 arch/x86/kvm/cpuid.c:1183 + kvm_vcpu_reset+0x13fb/0x1c20 arch/x86/kvm/x86.c:10885 + kvm_apic_accept_events+0x58f/0x8c0 arch/x86/kvm/lapic.c:2923 + vcpu_enter_guest+0xfd2/0x6d80 arch/x86/kvm/x86.c:9534 + vcpu_run+0x7f5/0x18d0 arch/x86/kvm/x86.c:9788 + kvm_arch_vcpu_ioctl_run+0x245b/0x2d10 arch/x86/kvm/x86.c:10020 + + Local variable ----dummy@kvm_vcpu_reset created at: + kvm_vcpu_reset+0x1fb/0x1c20 arch/x86/kvm/x86.c:10812 + kvm_apic_accept_events+0x58f/0x8c0 arch/x86/kvm/lapic.c:2923 + +Reported-by: syzbot+f3985126b746b3d59c9d@syzkaller.appspotmail.com +Reported-by: Alexander Potapenko +Fixes: 2a24be79b6b7 ("KVM: VMX: Set EDX at INIT with CPUID.0x1, Family-Model-Stepping") +Fixes: 7ff6c0350315 ("KVM: x86: Remove stateful CPUID handling") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Reviewed-by: Jim Mattson +Message-Id: <20210929222426.1855730-2-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/cpuid.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/cpuid.c ++++ b/arch/x86/kvm/cpuid.c +@@ -65,8 +65,8 @@ static inline struct kvm_cpuid_entry2 *c + for (i = 0; i < nent; i++) { + e = &entries[i]; + +- if (e->function == function && (e->index == index || +- !(e->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))) ++ if (e->function == function && ++ (!(e->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX) || e->index == index)) + return e; + } + diff --git a/queue-5.14/media-ir_toy-prevent-device-from-hanging-during-transmit.patch b/queue-5.14/media-ir_toy-prevent-device-from-hanging-during-transmit.patch new file mode 100644 index 00000000000..58444deb81d --- /dev/null +++ b/queue-5.14/media-ir_toy-prevent-device-from-hanging-during-transmit.patch @@ -0,0 +1,65 @@ +From f0c15b360fb65ee39849afe987c16eb3d0175d0d Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Tue, 14 Sep 2021 16:57:46 +0200 +Subject: media: ir_toy: prevent device from hanging during transmit + +From: Sean Young + +commit f0c15b360fb65ee39849afe987c16eb3d0175d0d upstream. + +If the IR Toy is receiving IR while a transmit is done, it may end up +hanging. We can prevent this from happening by re-entering sample mode +just before issuing the transmit command. + +Link: https://github.com/bengtmartensson/HarcHardware/discussions/25 + +Cc: stable@vger.kernel.org +Signed-off-by: Sean Young +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/ir_toy.c | 21 ++++++++++++++++++++- + 1 file changed, 20 insertions(+), 1 deletion(-) + +--- a/drivers/media/rc/ir_toy.c ++++ b/drivers/media/rc/ir_toy.c +@@ -24,6 +24,7 @@ static const u8 COMMAND_VERSION[] = { 'v + // End transmit and repeat reset command so we exit sump mode + static const u8 COMMAND_RESET[] = { 0xff, 0xff, 0, 0, 0, 0, 0 }; + static const u8 COMMAND_SMODE_ENTER[] = { 's' }; ++static const u8 COMMAND_SMODE_EXIT[] = { 0 }; + static const u8 COMMAND_TXSTART[] = { 0x26, 0x24, 0x25, 0x03 }; + + #define REPLY_XMITCOUNT 't' +@@ -309,12 +310,30 @@ static int irtoy_tx(struct rc_dev *rc, u + buf[i] = cpu_to_be16(v); + } + +- buf[count] = cpu_to_be16(0xffff); ++ buf[count] = 0xffff; + + irtoy->tx_buf = buf; + irtoy->tx_len = size; + irtoy->emitted = 0; + ++ // There is an issue where if the unit is receiving IR while the ++ // first TXSTART command is sent, the device might end up hanging ++ // with its led on. It does not respond to any command when this ++ // happens. To work around this, re-enter sample mode. ++ err = irtoy_command(irtoy, COMMAND_SMODE_EXIT, ++ sizeof(COMMAND_SMODE_EXIT), STATE_RESET); ++ if (err) { ++ dev_err(irtoy->dev, "exit sample mode: %d\n", err); ++ return err; ++ } ++ ++ err = irtoy_command(irtoy, COMMAND_SMODE_ENTER, ++ sizeof(COMMAND_SMODE_ENTER), STATE_COMMAND); ++ if (err) { ++ dev_err(irtoy->dev, "enter sample mode: %d\n", err); ++ return err; ++ } ++ + err = irtoy_command(irtoy, COMMAND_TXSTART, sizeof(COMMAND_TXSTART), + STATE_TX); + kfree(buf); diff --git a/queue-5.14/mmc-renesas_sdhi-fix-regression-with-hard-reset-on-old-sdhis.patch b/queue-5.14/mmc-renesas_sdhi-fix-regression-with-hard-reset-on-old-sdhis.patch new file mode 100644 index 00000000000..10625daef01 --- /dev/null +++ b/queue-5.14/mmc-renesas_sdhi-fix-regression-with-hard-reset-on-old-sdhis.patch @@ -0,0 +1,37 @@ +From b81bede4d138ce62f7342e27bf55ac93c8071818 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang +Date: Thu, 26 Aug 2021 10:21:07 +0200 +Subject: mmc: renesas_sdhi: fix regression with hard reset on old SDHIs + +From: Wolfram Sang + +commit b81bede4d138ce62f7342e27bf55ac93c8071818 upstream. + +Old SDHI instances have a default value for the reset register which +keeps it in reset state by default. So, when applying a hard reset we +need to manually leave the soft reset state as well. Later SDHI +instances have a different default value, the one we write manually now. + +Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible") +Signed-off-by: Wolfram Sang +Tested-by: Geert Uytterhoeven +Reported-by: Geert Uytterhoeven +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210826082107.47299-1-wsa+renesas@sang-engineering.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/renesas_sdhi_core.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/mmc/host/renesas_sdhi_core.c ++++ b/drivers/mmc/host/renesas_sdhi_core.c +@@ -582,6 +582,8 @@ static void renesas_sdhi_reset(struct tm + /* Unknown why but without polling reset status, it will hang */ + read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100, + false, priv->rstc); ++ /* At least SDHI_VER_GEN2_SDR50 needs manual release of reset */ ++ sd_ctrl_write16(host, CTL_RESET_SD, 0x0001); + priv->needs_adjust_hs400 = false; + renesas_sdhi_set_clock(host, host->clk_cache); + } else if (priv->scc_ctl) { diff --git a/queue-5.14/nbd-use-shifts-rather-than-multiplies.patch b/queue-5.14/nbd-use-shifts-rather-than-multiplies.patch new file mode 100644 index 00000000000..a1116eed3db --- /dev/null +++ b/queue-5.14/nbd-use-shifts-rather-than-multiplies.patch @@ -0,0 +1,176 @@ +From 41e76c6a3c83c85e849f10754b8632ea763d9be4 Mon Sep 17 00:00:00 2001 +From: Nick Desaulniers +Date: Mon, 20 Sep 2021 16:25:33 -0700 +Subject: nbd: use shifts rather than multiplies + +From: Nick Desaulniers + +commit 41e76c6a3c83c85e849f10754b8632ea763d9be4 upstream. + +commit fad7cd3310db ("nbd: add the check to prevent overflow in +__nbd_ioctl()") raised an issue from the fallback helpers added in +commit f0907827a8a9 ("compiler.h: enable builtin overflow checkers and +add fallback code") + +ERROR: modpost: "__divdi3" [drivers/block/nbd.ko] undefined! + +As Stephen Rothwell notes: + The added check_mul_overflow() call is being passed 64 bit values. + COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW is not set for this build (see + include/linux/overflow.h). + +Specifically, the helpers for checking whether the results of a +multiplication overflowed (__unsigned_mul_overflow, +__signed_add_overflow) use the division operator when +!COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW. This is problematic for 64b +operands on 32b hosts. + +This was fixed upstream by +commit 76ae847497bc ("Documentation: raise minimum supported version of +GCC to 5.1") +which is not suitable to be backported to stable. + +Further, __builtin_mul_overflow() would emit a libcall to a +compiler-rt-only symbol when compiling with clang < 14 for 32b targets. + +ld.lld: error: undefined symbol: __mulodi4 + +In order to keep stable buildable with GCC 4.9 and clang < 14, modify +struct nbd_config to instead track the number of bits of the block size; +reconstructing the block size using runtime checked shifts that are not +problematic for those compilers and in a ways that can be backported to +stable. + +In nbd_set_size, we do validate that the value of blksize must be a +power of two (POT) and is in the range of [512, PAGE_SIZE] (both +inclusive). + +This does modify the debugfs interface. + +Cc: stable@vger.kernel.org +Cc: Arnd Bergmann +Cc: Rasmus Villemoes +Link: https://github.com/ClangBuiltLinux/linux/issues/1438 +Link: https://lore.kernel.org/all/20210909182525.372ee687@canb.auug.org.au/ +Link: https://lore.kernel.org/stable/CAHk-=whiQBofgis_rkniz8GBP9wZtSZdcDEffgSLO62BUGV3gg@mail.gmail.com/ +Reported-by: Naresh Kamboju +Reported-by: Nathan Chancellor +Reported-by: Stephen Rothwell +Suggested-by: Kees Cook +Suggested-by: Linus Torvalds +Suggested-by: Pavel Machek +Signed-off-by: Nick Desaulniers +Reviewed-by: Josef Bacik +Link: https://lore.kernel.org/r/20210920232533.4092046-1-ndesaulniers@google.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/block/nbd.c | 29 +++++++++++++++++------------ + 1 file changed, 17 insertions(+), 12 deletions(-) + +--- a/drivers/block/nbd.c ++++ b/drivers/block/nbd.c +@@ -97,13 +97,18 @@ struct nbd_config { + + atomic_t recv_threads; + wait_queue_head_t recv_wq; +- loff_t blksize; ++ unsigned int blksize_bits; + loff_t bytesize; + #if IS_ENABLED(CONFIG_DEBUG_FS) + struct dentry *dbg_dir; + #endif + }; + ++static inline unsigned int nbd_blksize(struct nbd_config *config) ++{ ++ return 1u << config->blksize_bits; ++} ++ + struct nbd_device { + struct blk_mq_tag_set tag_set; + +@@ -147,7 +152,7 @@ static struct dentry *nbd_dbg_dir; + + #define NBD_MAGIC 0x68797548 + +-#define NBD_DEF_BLKSIZE 1024 ++#define NBD_DEF_BLKSIZE_BITS 10 + + static unsigned int nbds_max = 16; + static int max_part = 16; +@@ -350,12 +355,12 @@ static int nbd_set_size(struct nbd_devic + loff_t blksize) + { + if (!blksize) +- blksize = NBD_DEF_BLKSIZE; ++ blksize = 1u << NBD_DEF_BLKSIZE_BITS; + if (blksize < 512 || blksize > PAGE_SIZE || !is_power_of_2(blksize)) + return -EINVAL; + + nbd->config->bytesize = bytesize; +- nbd->config->blksize = blksize; ++ nbd->config->blksize_bits = __ffs(blksize); + + if (!nbd->task_recv) + return 0; +@@ -1370,7 +1375,7 @@ static int nbd_start_device(struct nbd_d + args->index = i; + queue_work(nbd->recv_workq, &args->work); + } +- return nbd_set_size(nbd, config->bytesize, config->blksize); ++ return nbd_set_size(nbd, config->bytesize, nbd_blksize(config)); + } + + static int nbd_start_device_ioctl(struct nbd_device *nbd, struct block_device *bdev) +@@ -1439,11 +1444,11 @@ static int __nbd_ioctl(struct block_devi + case NBD_SET_BLKSIZE: + return nbd_set_size(nbd, config->bytesize, arg); + case NBD_SET_SIZE: +- return nbd_set_size(nbd, arg, config->blksize); ++ return nbd_set_size(nbd, arg, nbd_blksize(config)); + case NBD_SET_SIZE_BLOCKS: +- if (check_mul_overflow((loff_t)arg, config->blksize, &bytesize)) ++ if (check_shl_overflow(arg, config->blksize_bits, &bytesize)) + return -EINVAL; +- return nbd_set_size(nbd, bytesize, config->blksize); ++ return nbd_set_size(nbd, bytesize, nbd_blksize(config)); + case NBD_SET_TIMEOUT: + nbd_set_cmd_timeout(nbd, arg); + return 0; +@@ -1509,7 +1514,7 @@ static struct nbd_config *nbd_alloc_conf + atomic_set(&config->recv_threads, 0); + init_waitqueue_head(&config->recv_wq); + init_waitqueue_head(&config->conn_wait); +- config->blksize = NBD_DEF_BLKSIZE; ++ config->blksize_bits = NBD_DEF_BLKSIZE_BITS; + atomic_set(&config->live_connections, 0); + try_module_get(THIS_MODULE); + return config; +@@ -1637,7 +1642,7 @@ static int nbd_dev_dbg_init(struct nbd_d + debugfs_create_file("tasks", 0444, dir, nbd, &nbd_dbg_tasks_fops); + debugfs_create_u64("size_bytes", 0444, dir, &config->bytesize); + debugfs_create_u32("timeout", 0444, dir, &nbd->tag_set.timeout); +- debugfs_create_u64("blocksize", 0444, dir, &config->blksize); ++ debugfs_create_u32("blocksize_bits", 0444, dir, &config->blksize_bits); + debugfs_create_file("flags", 0444, dir, nbd, &nbd_dbg_flags_fops); + + return 0; +@@ -1841,7 +1846,7 @@ nbd_device_policy[NBD_DEVICE_ATTR_MAX + + static int nbd_genl_size_set(struct genl_info *info, struct nbd_device *nbd) + { + struct nbd_config *config = nbd->config; +- u64 bsize = config->blksize; ++ u64 bsize = nbd_blksize(config); + u64 bytes = config->bytesize; + + if (info->attrs[NBD_ATTR_SIZE_BYTES]) +@@ -1850,7 +1855,7 @@ static int nbd_genl_size_set(struct genl + if (info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]) + bsize = nla_get_u64(info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]); + +- if (bytes != config->bytesize || bsize != config->blksize) ++ if (bytes != config->bytesize || bsize != nbd_blksize(config)) + return nbd_set_size(nbd, bytes, bsize); + return 0; + } diff --git a/queue-5.14/platform-x86-intel-hid-add-dmi-switches-allow-list.patch b/queue-5.14/platform-x86-intel-hid-add-dmi-switches-allow-list.patch new file mode 100644 index 00000000000..6b267928de2 --- /dev/null +++ b/queue-5.14/platform-x86-intel-hid-add-dmi-switches-allow-list.patch @@ -0,0 +1,88 @@ +From b201cb0ebe87b209e252d85668e517ac1929e250 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Jos=C3=A9=20Exp=C3=B3sito?= +Date: Mon, 20 Sep 2021 18:03:12 +0200 +Subject: platform/x86/intel: hid: Add DMI switches allow list +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: José Expósito + +commit b201cb0ebe87b209e252d85668e517ac1929e250 upstream. + +Some devices, even non convertible ones, can send incorrect +SW_TABLET_MODE reports. + +Add an allow list and accept such reports only from devices in it. + +Bug reported for Dell XPS 17 9710 on: +https://gitlab.freedesktop.org/libinput/libinput/-/issues/662 + +Reported-by: Tobias Gurtzick +Suggested-by: Hans de Goede +Tested-by: Tobias Gurtzick +Signed-off-by: José Expósito +Link: https://lore.kernel.org/r/20210920160312.9787-1-jose.exposito89@gmail.com +[hdegoede@redhat.com: Check dmi_switches_auto_add_allow_list only once] +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/intel-hid.c | 27 ++++++++++++++++++++++----- + 1 file changed, 22 insertions(+), 5 deletions(-) + +--- a/drivers/platform/x86/intel-hid.c ++++ b/drivers/platform/x86/intel-hid.c +@@ -118,12 +118,30 @@ static const struct dmi_system_id dmi_vg + { } + }; + ++/* ++ * Some devices, even non convertible ones, can send incorrect SW_TABLET_MODE ++ * reports. Accept such reports only from devices in this list. ++ */ ++static const struct dmi_system_id dmi_auto_add_switch[] = { ++ { ++ .matches = { ++ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "31" /* Convertible */), ++ }, ++ }, ++ { ++ .matches = { ++ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "32" /* Detachable */), ++ }, ++ }, ++ {} /* Array terminator */ ++}; ++ + struct intel_hid_priv { + struct input_dev *input_dev; + struct input_dev *array; + struct input_dev *switches; + bool wakeup_mode; +- bool dual_accel; ++ bool auto_add_switch; + }; + + #define HID_EVENT_FILTER_UUID "eeec56b3-4442-408f-a792-4edd4d758054" +@@ -452,10 +470,8 @@ static void notify_handler(acpi_handle h + * Some convertible have unreliable VGBS return which could cause incorrect + * SW_TABLET_MODE report, in these cases we enable support when receiving + * the first event instead of during driver setup. +- * +- * See dual_accel_detect.h for more info on the dual_accel check. + */ +- if (!priv->switches && !priv->dual_accel && (event == 0xcc || event == 0xcd)) { ++ if (!priv->switches && priv->auto_add_switch && (event == 0xcc || event == 0xcd)) { + dev_info(&device->dev, "switch event received, enable switches supports\n"); + err = intel_hid_switches_setup(device); + if (err) +@@ -596,7 +612,8 @@ static int intel_hid_probe(struct platfo + return -ENOMEM; + dev_set_drvdata(&device->dev, priv); + +- priv->dual_accel = dual_accel_detect(); ++ /* See dual_accel_detect.h for more info on the dual_accel check. */ ++ priv->auto_add_switch = dmi_check_system(dmi_auto_add_switch) && !dual_accel_detect(); + + err = intel_hid_input_setup(device); + if (err) { diff --git a/queue-5.14/ptp-fix-ptp_kvm_getcrosststamp-issue-for-x86-ptp_kvm.patch b/queue-5.14/ptp-fix-ptp_kvm_getcrosststamp-issue-for-x86-ptp_kvm.patch new file mode 100644 index 00000000000..d4891d6e828 --- /dev/null +++ b/queue-5.14/ptp-fix-ptp_kvm_getcrosststamp-issue-for-x86-ptp_kvm.patch @@ -0,0 +1,59 @@ +From 773e89ab0056aaa2baa1ffd9f044551654410104 Mon Sep 17 00:00:00 2001 +From: Zelin Deng +Date: Wed, 29 Sep 2021 13:13:49 +0800 +Subject: ptp: Fix ptp_kvm_getcrosststamp issue for x86 ptp_kvm + +From: Zelin Deng + +commit 773e89ab0056aaa2baa1ffd9f044551654410104 upstream. + +hv_clock is preallocated to have only HVC_BOOT_ARRAY_SIZE (64) elements; +if the PTP_SYS_OFFSET_PRECISE ioctl is executed on vCPUs whose index is +64 of higher, retrieving the struct pvclock_vcpu_time_info pointer with +"src = &hv_clock[cpu].pvti" will result in an out-of-bounds access and +a wild pointer. Change it to "this_cpu_pvti()" which is guaranteed to +be valid. + +Fixes: 95a3d4454bb1 ("Switch kvmclock data to a PER_CPU variable") +Signed-off-by: Zelin Deng +Cc: +Message-Id: <1632892429-101194-3-git-send-email-zelin.deng@linux.alibaba.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ptp/ptp_kvm_x86.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +--- a/drivers/ptp/ptp_kvm_x86.c ++++ b/drivers/ptp/ptp_kvm_x86.c +@@ -15,8 +15,6 @@ + #include + #include + +-struct pvclock_vsyscall_time_info *hv_clock; +- + static phys_addr_t clock_pair_gpa; + static struct kvm_clock_pairing clock_pair; + +@@ -28,8 +26,7 @@ int kvm_arch_ptp_init(void) + return -ENODEV; + + clock_pair_gpa = slow_virt_to_phys(&clock_pair); +- hv_clock = pvclock_get_pvti_cpu0_va(); +- if (!hv_clock) ++ if (!pvclock_get_pvti_cpu0_va()) + return -ENODEV; + + ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING, clock_pair_gpa, +@@ -64,10 +61,8 @@ int kvm_arch_ptp_get_crosststamp(u64 *cy + struct pvclock_vcpu_time_info *src; + unsigned int version; + long ret; +- int cpu; + +- cpu = smp_processor_id(); +- src = &hv_clock[cpu].pvti; ++ src = this_cpu_pvti(); + + do { + /* diff --git a/queue-5.14/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch b/queue-5.14/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch new file mode 100644 index 00000000000..1a742693962 --- /dev/null +++ b/queue-5.14/rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch @@ -0,0 +1,82 @@ +From bc0bdc5afaa740d782fbf936aaeebd65e5c2921d Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Wed, 15 Sep 2021 17:21:43 -0300 +Subject: RDMA/cma: Do not change route.addr.src_addr.ss_family + +From: Jason Gunthorpe + +commit bc0bdc5afaa740d782fbf936aaeebd65e5c2921d upstream. + +If the state is not idle then rdma_bind_addr() will immediately fail and +no change to global state should happen. + +For instance if the state is already RDMA_CM_LISTEN then this will corrupt +the src_addr and would cause the test in cma_cancel_operation(): + + if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) + +To view a mangled src_addr, eg with a IPv6 loopback address but an IPv4 +family, failing the test. + +This would manifest as this trace from syzkaller: + + BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 + Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 + + CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 + Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 + Call Trace: + __dump_stack lib/dump_stack.c:79 [inline] + dump_stack+0x141/0x1d7 lib/dump_stack.c:120 + print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 + __kasan_report mm/kasan/report.c:399 [inline] + kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 + __list_add_valid+0x93/0xa0 lib/list_debug.c:26 + __list_add include/linux/list.h:67 [inline] + list_add_tail include/linux/list.h:100 [inline] + cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] + rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 + ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 + ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 + vfs_write+0x28e/0xa30 fs/read_write.c:603 + ksys_write+0x1ee/0x250 fs/read_write.c:658 + do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +Which is indicating that an rdma_id_private was destroyed without doing +cma_cancel_listens(). + +Instead of trying to re-use the src_addr memory to indirectly create an +any address build one explicitly on the stack and bind to that as any +other normal flow would do. + +Link: https://lore.kernel.org/r/0-v1-9fbb33f5e201+2a-cma_listen_jgg@nvidia.com +Cc: stable@vger.kernel.org +Fixes: 732d41c545bb ("RDMA/cma: Make the locking for automatic state transition more clear") +Reported-by: syzbot+6bb0528b13611047209c@syzkaller.appspotmail.com +Tested-by: Hao Sun +Reviewed-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/cma.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/infiniband/core/cma.c ++++ b/drivers/infiniband/core/cma.c +@@ -3768,9 +3768,13 @@ int rdma_listen(struct rdma_cm_id *id, i + int ret; + + if (!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, RDMA_CM_LISTEN)) { ++ struct sockaddr_in any_in = { ++ .sin_family = AF_INET, ++ .sin_addr.s_addr = htonl(INADDR_ANY), ++ }; ++ + /* For a well behaved ULP state will be RDMA_CM_IDLE */ +- id->route.addr.src_addr.ss_family = AF_INET; +- ret = rdma_bind_addr(id, cma_src_addr(id_priv)); ++ ret = rdma_bind_addr(id, (struct sockaddr *)&any_in); + if (ret) + return ret; + if (WARN_ON(!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, diff --git a/queue-5.14/rdma-cma-ensure-rdma_addr_cancel-happens-before-issuing-more-requests.patch b/queue-5.14/rdma-cma-ensure-rdma_addr_cancel-happens-before-issuing-more-requests.patch new file mode 100644 index 00000000000..357e3c346df --- /dev/null +++ b/queue-5.14/rdma-cma-ensure-rdma_addr_cancel-happens-before-issuing-more-requests.patch @@ -0,0 +1,125 @@ +From 305d568b72f17f674155a2a8275f865f207b3808 Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Thu, 16 Sep 2021 15:34:46 -0300 +Subject: RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests + +From: Jason Gunthorpe + +commit 305d568b72f17f674155a2a8275f865f207b3808 upstream. + +The FSM can run in a circle allowing rdma_resolve_ip() to be called twice +on the same id_priv. While this cannot happen without going through the +work, it violates the invariant that the same address resolution +background request cannot be active twice. + + CPU 1 CPU 2 + +rdma_resolve_addr(): + RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY + rdma_resolve_ip(addr_handler) #1 + + process_one_req(): for #1 + addr_handler(): + RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND + mutex_unlock(&id_priv->handler_mutex); + [.. handler still running ..] + +rdma_resolve_addr(): + RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY + rdma_resolve_ip(addr_handler) + !! two requests are now on the req_list + +rdma_destroy_id(): + destroy_id_handler_unlock(): + _destroy_id(): + cma_cancel_operation(): + rdma_addr_cancel() + + // process_one_req() self removes it + spin_lock_bh(&lock); + cancel_delayed_work(&req->work); + if (!list_empty(&req->list)) == true + + ! rdma_addr_cancel() returns after process_on_req #1 is done + + kfree(id_priv) + + process_one_req(): for #2 + addr_handler(): + mutex_lock(&id_priv->handler_mutex); + !! Use after free on id_priv + +rdma_addr_cancel() expects there to be one req on the list and only +cancels the first one. The self-removal behavior of the work only happens +after the handler has returned. This yields a situations where the +req_list can have two reqs for the same "handle" but rdma_addr_cancel() +only cancels the first one. + +The second req remains active beyond rdma_destroy_id() and will +use-after-free id_priv once it inevitably triggers. + +Fix this by remembering if the id_priv has called rdma_resolve_ip() and +always cancel before calling it again. This ensures the req_list never +gets more than one item in it and doesn't cost anything in the normal flow +that never uses this strange error path. + +Link: https://lore.kernel.org/r/0-v1-3bc675b8006d+22-syz_cancel_uaf_jgg@nvidia.com +Cc: stable@vger.kernel.org +Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager") +Reported-by: syzbot+dc3dfba010d7671e05f5@syzkaller.appspotmail.com +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/cma.c | 23 +++++++++++++++++++++++ + drivers/infiniband/core/cma_priv.h | 1 + + 2 files changed, 24 insertions(+) + +--- a/drivers/infiniband/core/cma.c ++++ b/drivers/infiniband/core/cma.c +@@ -1776,6 +1776,14 @@ static void cma_cancel_operation(struct + { + switch (state) { + case RDMA_CM_ADDR_QUERY: ++ /* ++ * We can avoid doing the rdma_addr_cancel() based on state, ++ * only RDMA_CM_ADDR_QUERY has a work that could still execute. ++ * Notice that the addr_handler work could still be exiting ++ * outside this state, however due to the interaction with the ++ * handler_mutex the work is guaranteed not to touch id_priv ++ * during exit. ++ */ + rdma_addr_cancel(&id_priv->id.route.addr.dev_addr); + break; + case RDMA_CM_ROUTE_QUERY: +@@ -3410,6 +3418,21 @@ int rdma_resolve_addr(struct rdma_cm_id + if (dst_addr->sa_family == AF_IB) { + ret = cma_resolve_ib_addr(id_priv); + } else { ++ /* ++ * The FSM can return back to RDMA_CM_ADDR_BOUND after ++ * rdma_resolve_ip() is called, eg through the error ++ * path in addr_handler(). If this happens the existing ++ * request must be canceled before issuing a new one. ++ * Since canceling a request is a bit slow and this ++ * oddball path is rare, keep track once a request has ++ * been issued. The track turns out to be a permanent ++ * state since this is the only cancel as it is ++ * immediately before rdma_resolve_ip(). ++ */ ++ if (id_priv->used_resolve_ip) ++ rdma_addr_cancel(&id->route.addr.dev_addr); ++ else ++ id_priv->used_resolve_ip = 1; + ret = rdma_resolve_ip(cma_src_addr(id_priv), dst_addr, + &id->route.addr.dev_addr, + timeout_ms, addr_handler, +--- a/drivers/infiniband/core/cma_priv.h ++++ b/drivers/infiniband/core/cma_priv.h +@@ -91,6 +91,7 @@ struct rdma_id_private { + u8 afonly; + u8 timeout; + u8 min_rnr_timer; ++ u8 used_resolve_ip; + enum ib_gid_type gid_type; + + /* diff --git a/queue-5.14/series b/queue-5.14/series index 587788ca371..6997e2adba0 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -45,3 +45,29 @@ hwmon-w83791d-fix-null-pointer-dereference-by-removing-unnecessary-structure-fie gpio-pca953x-do-not-ignore-i2c-errors.patch scsi-ufs-fix-illegal-offset-in-upiu-event-trace.patch mac80211-fix-use-after-free-in-ccmp-gcmp-rx.patch +platform-x86-intel-hid-add-dmi-switches-allow-list.patch +x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch +ptp-fix-ptp_kvm_getcrosststamp-issue-for-x86-ptp_kvm.patch +kvm-x86-fix-stack-out-of-bounds-memory-access-from-ioapic_write_indirect.patch +kvm-x86-nsvm-don-t-copy-virt_ext-from-vmcb12.patch +kvm-x86-clear-kvm-s-cached-guest-cr3-at-reset-init.patch +kvm-x86-swap-order-of-cpuid-entry-index-vs.-significant-flag-checks.patch +kvm-nvmx-filter-out-all-unsupported-controls-when-evmcs-was-activated.patch +kvm-sev-update-svm_vm_copy_asid_from-for-sev-es.patch +kvm-sev-pin-guest-memory-for-write-for-receive_update_data.patch +kvm-sev-acquire-vcpu-mutex-when-updating-vmsa.patch +kvm-sev-allow-some-commands-for-mirror-vm.patch +kvm-svm-fix-missing-sev_decommission-in-sev_receive_start.patch +kvm-nvmx-fix-nested-bus-lock-vm-exit.patch +kvm-vmx-fix-a-tsx_ctrl_cpuid_clear-field-mask-issue.patch +mmc-renesas_sdhi-fix-regression-with-hard-reset-on-old-sdhis.patch +media-ir_toy-prevent-device-from-hanging-during-transmit.patch +rdma-cma-do-not-change-route.addr.src_addr.ss_family.patch +rdma-cma-ensure-rdma_addr_cancel-happens-before-issuing-more-requests.patch +nbd-use-shifts-rather-than-multiplies.patch +drm-amd-display-initialize-backlight_ramping_override-to-false.patch +drm-amd-display-pass-pci-deviceid-into-dc.patch +drm-amd-display-fix-display-flicker-on-embedded-panels.patch +drm-amdgpu-force-exit-gfxoff-on-sdma-resume-for-rmb-s0ix.patch +drm-amdgpu-check-tiling-flags-when-creating-fb-on-gfx8.patch +drm-amdgpu-correct-initial-cp_hqd_quantum-for-gfx9.patch diff --git a/queue-5.14/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch b/queue-5.14/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch new file mode 100644 index 00000000000..b246e298f35 --- /dev/null +++ b/queue-5.14/x86-kvmclock-move-this_cpu_pvti-into-kvmclock.h.patch @@ -0,0 +1,69 @@ +From ad9af930680bb396c87582edc172b3a7cf2a3fbf Mon Sep 17 00:00:00 2001 +From: Zelin Deng +Date: Wed, 29 Sep 2021 13:13:48 +0800 +Subject: x86/kvmclock: Move this_cpu_pvti into kvmclock.h + +From: Zelin Deng + +commit ad9af930680bb396c87582edc172b3a7cf2a3fbf upstream. + +There're other modules might use hv_clock_per_cpu variable like ptp_kvm, +so move it into kvmclock.h and export the symbol to make it visiable to +other modules. + +Signed-off-by: Zelin Deng +Cc: +Message-Id: <1632892429-101194-2-git-send-email-zelin.deng@linux.alibaba.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/kvmclock.h | 14 ++++++++++++++ + arch/x86/kernel/kvmclock.c | 13 ++----------- + 2 files changed, 16 insertions(+), 11 deletions(-) + +--- a/arch/x86/include/asm/kvmclock.h ++++ b/arch/x86/include/asm/kvmclock.h +@@ -2,6 +2,20 @@ + #ifndef _ASM_X86_KVM_CLOCK_H + #define _ASM_X86_KVM_CLOCK_H + ++#include ++ + extern struct clocksource kvm_clock; + ++DECLARE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu); ++ ++static inline struct pvclock_vcpu_time_info *this_cpu_pvti(void) ++{ ++ return &this_cpu_read(hv_clock_per_cpu)->pvti; ++} ++ ++static inline struct pvclock_vsyscall_time_info *this_cpu_hvclock(void) ++{ ++ return this_cpu_read(hv_clock_per_cpu); ++} ++ + #endif /* _ASM_X86_KVM_CLOCK_H */ +--- a/arch/x86/kernel/kvmclock.c ++++ b/arch/x86/kernel/kvmclock.c +@@ -49,18 +49,9 @@ early_param("no-kvmclock-vsyscall", pars + static struct pvclock_vsyscall_time_info + hv_clock_boot[HVC_BOOT_ARRAY_SIZE] __bss_decrypted __aligned(PAGE_SIZE); + static struct pvclock_wall_clock wall_clock __bss_decrypted; +-static DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu); + static struct pvclock_vsyscall_time_info *hvclock_mem; +- +-static inline struct pvclock_vcpu_time_info *this_cpu_pvti(void) +-{ +- return &this_cpu_read(hv_clock_per_cpu)->pvti; +-} +- +-static inline struct pvclock_vsyscall_time_info *this_cpu_hvclock(void) +-{ +- return this_cpu_read(hv_clock_per_cpu); +-} ++DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu); ++EXPORT_PER_CPU_SYMBOL_GPL(hv_clock_per_cpu); + + /* + * The wallclock is the time of day when we booted. Since then, some time may