From: Greg Kroah-Hartman Date: Mon, 12 Sep 2022 14:44:52 +0000 (+0200) Subject: 5.19-stable patches X-Git-Tag: v5.19.9~12 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=81e7667b5322a860bf21832dedc97f3a28747f84;p=thirdparty%2Fkernel%2Fstable-queue.git 5.19-stable patches added patches: arm64-bti-disable-in-kernel-bti-when-cross-section-thunks-are-broken.patch iommu-fix-false-ownership-failure-on-amd-systems-with-pasid-activated.patch iommu-virtio-fix-interaction-with-vfio.patch iommu-vt-d-correctly-calculate-sagaw-value-of-iommu.patch --- diff --git a/queue-5.19/arm64-bti-disable-in-kernel-bti-when-cross-section-thunks-are-broken.patch b/queue-5.19/arm64-bti-disable-in-kernel-bti-when-cross-section-thunks-are-broken.patch new file mode 100644 index 00000000000..e969b24b19c --- /dev/null +++ b/queue-5.19/arm64-bti-disable-in-kernel-bti-when-cross-section-thunks-are-broken.patch @@ -0,0 +1,48 @@ +From c0a454b9044fdc99486853aa424e5b3be2107078 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Mon, 5 Sep 2022 15:22:55 +0100 +Subject: arm64/bti: Disable in kernel BTI when cross section thunks are broken + +From: Mark Brown + +commit c0a454b9044fdc99486853aa424e5b3be2107078 upstream. + +GCC does not insert a `bti c` instruction at the beginning of a function +when it believes that all callers reach the function through a direct +branch[1]. Unfortunately the logic it uses to determine this is not +sufficiently robust, for example not taking account of functions being +placed in different sections which may be loaded separately, so we may +still see thunks being generated to these functions. If that happens, +the first instruction in the callee function will result in a Branch +Target Exception due to the missing landing pad. + +While this has currently only been observed in the case of modules +having their main code loaded sufficiently far from their init section +to require thunks it could potentially happen for other cases so the +safest thing is to disable BTI for the kernel when building with an +affected toolchain. + +[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 + +Reported-by: D Scott Phillips +[Bits of the commit message are lifted from his report & workaround] +Signed-off-by: Mark Brown +Link: https://lore.kernel.org/r/20220905142255.591990-1-broonie@kernel.org +Cc: # v5.10+ +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/Kconfig | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm64/Kconfig ++++ b/arch/arm64/Kconfig +@@ -1884,6 +1884,8 @@ config ARM64_BTI_KERNEL + depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI + # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697 + depends on !CC_IS_GCC || GCC_VERSION >= 100100 ++ # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 ++ depends on !CC_IS_GCC + # https://github.com/llvm/llvm-project/commit/a88c722e687e6780dcd6a58718350dc76fcc4cc9 + depends on !CC_IS_CLANG || CLANG_VERSION >= 120000 + depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS) diff --git a/queue-5.19/iommu-fix-false-ownership-failure-on-amd-systems-with-pasid-activated.patch b/queue-5.19/iommu-fix-false-ownership-failure-on-amd-systems-with-pasid-activated.patch new file mode 100644 index 00000000000..69ed54012ef --- /dev/null +++ b/queue-5.19/iommu-fix-false-ownership-failure-on-amd-systems-with-pasid-activated.patch @@ -0,0 +1,98 @@ +From 2380f1e8195ef612deea1dc7a3d611c5d2b9b56a Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Fri, 9 Sep 2022 16:46:31 -0300 +Subject: iommu: Fix false ownership failure on AMD systems with PASID activated + +From: Jason Gunthorpe + +commit 2380f1e8195ef612deea1dc7a3d611c5d2b9b56a upstream. + +The AMD IOMMU driver cannot activate PASID mode on a RID without the RID's +translation being set to IDENTITY. Further it requires changing the RID's +page table layout from the normal v1 IOMMU_DOMAIN_IDENTITY layout to a +different v2 layout. + +It does this by creating a new iommu_domain, configuring that domain for +v2 identity operation and then attaching it to the group, from within the +driver. This logic assumes the group is already set to the IDENTITY domain +and is being used by the DMA API. + +However, since the ownership logic is based on the group's domain pointer +equaling the default domain to detect DMA API ownership, this causes it to +look like the group is not attached to the DMA API any more. This blocks +attaching drivers to any other devices in the group. + +In a real system this manifests itself as the HD-audio devices on some AMD +platforms losing their device drivers. + +Work around this unique behavior of the AMD driver by checking for +equality of IDENTITY domains based on their type, not their pointer +value. This allows the AMD driver to have two IDENTITY domains for +internal purposes without breaking the check. + +Have the AMD driver properly declare that the special domain it created is +actually an IDENTITY domain. + +Cc: Robin Murphy +Cc: stable@vger.kernel.org +Fixes: 512881eacfa7 ("bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management") +Reported-by: Takashi Iwai +Tested-by: Takashi Iwai +Signed-off-by: Jason Gunthorpe +Reviewed-by: Robin Murphy +Link: https://lore.kernel.org/r/0-v1-ea566e16b06b+811-amd_owner_jgg@nvidia.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/amd/iommu_v2.c | 2 ++ + drivers/iommu/iommu.c | 21 +++++++++++++++++++-- + 2 files changed, 21 insertions(+), 2 deletions(-) + +--- a/drivers/iommu/amd/iommu_v2.c ++++ b/drivers/iommu/amd/iommu_v2.c +@@ -786,6 +786,8 @@ int amd_iommu_init_device(struct pci_dev + if (dev_state->domain == NULL) + goto out_free_states; + ++ /* See iommu_is_default_domain() */ ++ dev_state->domain->type = IOMMU_DOMAIN_IDENTITY; + amd_iommu_domain_direct_map(dev_state->domain); + + ret = amd_iommu_domain_enable_v2(dev_state->domain, pasids); +--- a/drivers/iommu/iommu.c ++++ b/drivers/iommu/iommu.c +@@ -3089,6 +3089,24 @@ out: + return ret; + } + ++static bool iommu_is_default_domain(struct iommu_group *group) ++{ ++ if (group->domain == group->default_domain) ++ return true; ++ ++ /* ++ * If the default domain was set to identity and it is still an identity ++ * domain then we consider this a pass. This happens because of ++ * amd_iommu_init_device() replacing the default idenytity domain with an ++ * identity domain that has a different configuration for AMDGPU. ++ */ ++ if (group->default_domain && ++ group->default_domain->type == IOMMU_DOMAIN_IDENTITY && ++ group->domain && group->domain->type == IOMMU_DOMAIN_IDENTITY) ++ return true; ++ return false; ++} ++ + /** + * iommu_device_use_default_domain() - Device driver wants to handle device + * DMA through the kernel DMA API. +@@ -3107,8 +3125,7 @@ int iommu_device_use_default_domain(stru + + mutex_lock(&group->mutex); + if (group->owner_cnt) { +- if (group->domain != group->default_domain || +- group->owner) { ++ if (group->owner || !iommu_is_default_domain(group)) { + ret = -EBUSY; + goto unlock_out; + } diff --git a/queue-5.19/iommu-virtio-fix-interaction-with-vfio.patch b/queue-5.19/iommu-virtio-fix-interaction-with-vfio.patch new file mode 100644 index 00000000000..9d851a26726 --- /dev/null +++ b/queue-5.19/iommu-virtio-fix-interaction-with-vfio.patch @@ -0,0 +1,92 @@ +From 91c98fe7941499e4127cdc359c30841b873dd43a Mon Sep 17 00:00:00 2001 +From: Jean-Philippe Brucker +Date: Thu, 25 Aug 2022 16:46:24 +0100 +Subject: iommu/virtio: Fix interaction with VFIO + +From: Jean-Philippe Brucker + +commit 91c98fe7941499e4127cdc359c30841b873dd43a upstream. + +Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache +coherence") requires IOMMU drivers to advertise +IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does +not provide to userspace the ability to maintain coherency through cache +invalidations, it requires hardware coherency. Advertise the capability +in order to restore VFIO support. + +The meaning of IOMMU_CAP_CACHE_COHERENCY also changed from "IOMMU can +enforce cache coherent DMA transactions" to "IOMMU_CACHE is supported". +While virtio-iommu cannot enforce coherency (of PCIe no-snoop +transactions), it does support IOMMU_CACHE. + +We can distinguish different cases of non-coherent DMA: + +(1) When accesses from a hardware endpoint are not coherent. The host + would describe such a device using firmware methods ('dma-coherent' + in device-tree, '_CCA' in ACPI), since they are also needed without + a vIOMMU. In this case mappings are created without IOMMU_CACHE. + virtio-iommu doesn't need any additional support. It sends the same + requests as for coherent devices. + +(2) When the physical IOMMU supports non-cacheable mappings. Supporting + those would require a new feature in virtio-iommu, new PROBE request + property and MAP flags. Device drivers would use a new API to + discover this since it depends on the architecture and the physical + IOMMU. + +(3) When the hardware supports PCIe no-snoop. It is possible for + assigned PCIe devices to issue no-snoop transactions, and the + virtio-iommu specification is lacking any mention of this. + + Arm platforms don't necessarily support no-snoop, and those that do + cannot enforce coherency of no-snoop transactions. Device drivers + must be careful about assuming that no-snoop transactions won't end + up cached; see commit e02f5c1bb228 ("drm: disable uncached DMA + optimization for ARM and arm64"). On x86 platforms, the host may or + may not enforce coherency of no-snoop transactions with the physical + IOMMU. But according to the above commit, on x86 a driver which + assumes that no-snoop DMA is compatible with uncached CPU mappings + will also work if the host enforces coherency. + + Although these issues are not specific to virtio-iommu, it could be + used to facilitate discovery and configuration of no-snoop. This + would require a new feature bit, PROBE property and ATTACH/MAP + flags. + +Cc: stable@vger.kernel.org +Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") +Signed-off-by: Jean-Philippe Brucker +Reviewed-by: Robin Murphy +Link: https://lore.kernel.org/r/20220825154622.86759-1-jean-philippe@linaro.org +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/virtio-iommu.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c +index 08eeafc9529f..80151176ba12 100644 +--- a/drivers/iommu/virtio-iommu.c ++++ b/drivers/iommu/virtio-iommu.c +@@ -1006,7 +1006,18 @@ static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args) + return iommu_fwspec_add_ids(dev, args->args, 1); + } + ++static bool viommu_capable(enum iommu_cap cap) ++{ ++ switch (cap) { ++ case IOMMU_CAP_CACHE_COHERENCY: ++ return true; ++ default: ++ return false; ++ } ++} ++ + static struct iommu_ops viommu_ops = { ++ .capable = viommu_capable, + .domain_alloc = viommu_domain_alloc, + .probe_device = viommu_probe_device, + .probe_finalize = viommu_probe_finalize, +-- +2.37.3 + diff --git a/queue-5.19/iommu-vt-d-correctly-calculate-sagaw-value-of-iommu.patch b/queue-5.19/iommu-vt-d-correctly-calculate-sagaw-value-of-iommu.patch new file mode 100644 index 00000000000..6b5d1c3ee5a --- /dev/null +++ b/queue-5.19/iommu-vt-d-correctly-calculate-sagaw-value-of-iommu.patch @@ -0,0 +1,72 @@ +From 53fc7ad6edf210b497230ce74b61b322a202470c Mon Sep 17 00:00:00 2001 +From: Lu Baolu +Date: Tue, 23 Aug 2022 14:15:55 +0800 +Subject: iommu/vt-d: Correctly calculate sagaw value of IOMMU + +From: Lu Baolu + +commit 53fc7ad6edf210b497230ce74b61b322a202470c upstream. + +The Intel IOMMU driver possibly selects between the first-level and the +second-level translation tables for DMA address translation. However, +the levels of page-table walks for the 4KB base page size are calculated +from the SAGAW field of the capability register, which is only valid for +the second-level page table. This causes the IOMMU driver to stop working +if the hardware (or the emulated IOMMU) advertises only first-level +translation capability and reports the SAGAW field as 0. + +This solves the above problem by considering both the first level and the +second level when calculating the supported page table levels. + +Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") +Cc: stable@vger.kernel.org +Signed-off-by: Lu Baolu +Link: https://lore.kernel.org/r/20220817023558.3253263-1-baolu.lu@linux.intel.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/iommu.c | 28 +++++++++++++++++++++++++--- + 1 file changed, 25 insertions(+), 3 deletions(-) + +--- a/drivers/iommu/intel/iommu.c ++++ b/drivers/iommu/intel/iommu.c +@@ -422,14 +422,36 @@ static inline int domain_pfn_supported(s + return !(addr_width < BITS_PER_LONG && pfn >> addr_width); + } + ++/* ++ * Calculate the Supported Adjusted Guest Address Widths of an IOMMU. ++ * Refer to 11.4.2 of the VT-d spec for the encoding of each bit of ++ * the returned SAGAW. ++ */ ++static unsigned long __iommu_calculate_sagaw(struct intel_iommu *iommu) ++{ ++ unsigned long fl_sagaw, sl_sagaw; ++ ++ fl_sagaw = BIT(2) | (cap_fl1gp_support(iommu->cap) ? BIT(3) : 0); ++ sl_sagaw = cap_sagaw(iommu->cap); ++ ++ /* Second level only. */ ++ if (!sm_supported(iommu) || !ecap_flts(iommu->ecap)) ++ return sl_sagaw; ++ ++ /* First level only. */ ++ if (!ecap_slts(iommu->ecap)) ++ return fl_sagaw; ++ ++ return fl_sagaw & sl_sagaw; ++} ++ + static int __iommu_calculate_agaw(struct intel_iommu *iommu, int max_gaw) + { + unsigned long sagaw; + int agaw; + +- sagaw = cap_sagaw(iommu->cap); +- for (agaw = width_to_agaw(max_gaw); +- agaw >= 0; agaw--) { ++ sagaw = __iommu_calculate_sagaw(iommu); ++ for (agaw = width_to_agaw(max_gaw); agaw >= 0; agaw--) { + if (test_bit(agaw, &sagaw)) + break; + } diff --git a/queue-5.19/series b/queue-5.19/series index f46a00b9038..c1bd2ae8c9c 100644 --- a/queue-5.19/series +++ b/queue-5.19/series @@ -184,3 +184,7 @@ hwmon-asus-ec-sensors-add-support-for-maximus-xi-her.patch hwmon-asus-ec-sensors-add-missing-sensors-for-x570-i.patch hwmon-asus-ec-sensors-add-definitions-for-rog-zenith.patch hwmon-asus-ec-sensors-autoload-module-via-dmi-data.patch +arm64-bti-disable-in-kernel-bti-when-cross-section-thunks-are-broken.patch +iommu-vt-d-correctly-calculate-sagaw-value-of-iommu.patch +iommu-virtio-fix-interaction-with-vfio.patch +iommu-fix-false-ownership-failure-on-amd-systems-with-pasid-activated.patch