head 1.2; access; symbols pkgsrc-2025Q3:1.1.0.18 pkgsrc-2025Q3-base:1.1 pkgsrc-2025Q2:1.1.0.16 pkgsrc-2025Q2-base:1.1 pkgsrc-2025Q1:1.1.0.14 pkgsrc-2025Q1-base:1.1 pkgsrc-2024Q4:1.1.0.12 pkgsrc-2024Q4-base:1.1 pkgsrc-2024Q3:1.1.0.10 pkgsrc-2024Q3-base:1.1 pkgsrc-2024Q2:1.1.0.8 pkgsrc-2024Q2-base:1.1 pkgsrc-2024Q1:1.1.0.6 pkgsrc-2024Q1-base:1.1 pkgsrc-2023Q4:1.1.0.4 pkgsrc-2023Q4-base:1.1 pkgsrc-2023Q3:1.1.0.2; locks; strict; comment @# @; 1.2 date 2025.10.21.13.42.55; author bouyer; state dead; branches; next 1.1; commitid 7iYGhItznjMPorfG; 1.1 date 2023.11.15.15.59.36; author bouyer; state Exp; branches 1.1.2.1; next ; commitid ChAJVaTOI2nkQIME; 1.1.2.1 date 2023.11.15.15.59.36; author bsiegert; state dead; branches; next 1.1.2.2; commitid GoFxWjHbRICPvANE; 1.1.2.2 date 2023.11.22.09.37.25; author bsiegert; state Exp; branches; next ; commitid GoFxWjHbRICPvANE; desc @@ 1.2 log @remove xenkernel415 and xentools415. Xen 4.15 is EOL upstream @ text @$NetBSD: patch-XSA445,v 1.1 2023/11/15 15:59:36 bouyer Exp $ From 9877bb3af60ef2b543742835c49de7d0108cdca9 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 11 Oct 2023 13:14:21 +0200 Subject: [PATCH] iommu/amd-vi: use correct level for quarantine domain page tables MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current setup of the quarantine page tables assumes that the quarantine domain (dom_io) has been initialized with an address width of DEFAULT_DOMAIN_ADDRESS_WIDTH (48). However dom_io being a PV domain gets the AMD-Vi IOMMU page tables levels based on the maximum (hot pluggable) RAM address, and hence on systems with no RAM above the 512GB mark only 3 page-table levels are configured in the IOMMU. On systems without RAM above the 512GB boundary amd_iommu_quarantine_init() will setup page tables for the scratch page with 4 levels, while the IOMMU will be configured to use 3 levels only. The page destined to be used as level 1, and to contain a directory of PTEs ends up being the address in a PTE itself, and thus level 1 page becomes the leaf page. Without the level mismatch it's level 0 page that should be the leaf page instead. The level 1 page won't be used as such, and hence it's not possible to use it to gain access to other memory on the system. However that page is not cleared in amd_iommu_quarantine_init() as part of re-initialization of the device quarantine page tables, and hence data on the level 1 page can be leaked between device usages. Fix this by making sure the paging levels setup by amd_iommu_quarantine_init() match the number configured on the IOMMUs. Note that IVMD regions are not affected by this issue, as those areas are mapped taking the configured paging levels into account. This is XSA-445 / CVE-2023-46835 Fixes: ea38867831da ('x86 / iommu: set up a scratch page in the quarantine domain') Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- xen/drivers/passthrough/amd/iommu_map.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c index b4c182449131..3473db4c1efc 100644 --- xen/drivers/passthrough/amd/iommu_map.c.orig +++ xen/drivers/passthrough/amd/iommu_map.c @@@@ -584,9 +584,7 @@@@ static int fill_qpt(union amd_iommu_pte *this, unsigned int level, int amd_iommu_quarantine_init(struct pci_dev *pdev) { struct domain_iommu *hd = dom_iommu(dom_io); - unsigned long end_gfn = - 1ul << (DEFAULT_DOMAIN_ADDRESS_WIDTH - PAGE_SHIFT); - unsigned int level = amd_iommu_get_paging_mode(end_gfn); + unsigned int level = hd->arch.amd.paging_mode; unsigned int req_id = get_dma_requestor_id(pdev->seg, pdev->sbdf.bdf); const struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg); int rc; base-commit: 4a4daf6bddbe8a741329df5cc8768f7dec664aed -- 2.30.2 @ 1.1 log @xen*415: apply upstream patches for Xen Security Advisory XSA-439, XSA-440, XSA-442, XSA-443, XSA-444, XSA-445, XSA-446 bump PKGREVISIONs @ text @d1 1 a1 1 $NetBSD: $ @ 1.1.2.1 log @file patch-XSA445 was added on branch pkgsrc-2023Q3 on 2023-11-22 09:37:25 +0000 @ text @d1 67 @ 1.1.2.2 log @Pullup ticket #6823 - requested by bouyer sysutils/xenkernel415: security fix sysutils/xentools415: security fix Revisions pulled up: - sysutils/xenkernel415/Makefile 1.12 - sysutils/xenkernel415/distinfo 1.11 - sysutils/xenkernel415/patches/patch-XSA439 1.1 - sysutils/xenkernel415/patches/patch-XSA442 1.1 - sysutils/xenkernel415/patches/patch-XSA444 1.1 - sysutils/xenkernel415/patches/patch-XSA445 1.1 - sysutils/xenkernel415/patches/patch-XSA446 1.1 - sysutils/xentools415/Makefile 1.28 - sysutils/xentools415/PLIST 1.4 - sysutils/xentools415/distinfo 1.14 - sysutils/xentools415/patches/patch-XSA440 1.1 - sysutils/xentools415/patches/patch-XSA443 1.1 --- Module Name: pkgsrc Committed By: bouyer Date: Wed Nov 15 15:59:36 UTC 2023 Modified Files: pkgsrc/sysutils/xenkernel415: Makefile distinfo pkgsrc/sysutils/xentools415: Makefile PLIST distinfo Added Files: pkgsrc/sysutils/xenkernel415/patches: patch-XSA439 patch-XSA442 patch-XSA444 patch-XSA445 patch-XSA446 pkgsrc/sysutils/xentools415/patches: patch-XSA440 patch-XSA443 Log Message: xen*415: apply upstream patches for Xen Security Advisory XSA-439, XSA-440, XSA-442, XSA-443, XSA-444, XSA-445, XSA-446 bump PKGREVISIONs @ text @a0 67 $NetBSD: patch-XSA445,v 1.1 2023/11/15 15:59:36 bouyer Exp $ From 9877bb3af60ef2b543742835c49de7d0108cdca9 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 11 Oct 2023 13:14:21 +0200 Subject: [PATCH] iommu/amd-vi: use correct level for quarantine domain page tables MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current setup of the quarantine page tables assumes that the quarantine domain (dom_io) has been initialized with an address width of DEFAULT_DOMAIN_ADDRESS_WIDTH (48). However dom_io being a PV domain gets the AMD-Vi IOMMU page tables levels based on the maximum (hot pluggable) RAM address, and hence on systems with no RAM above the 512GB mark only 3 page-table levels are configured in the IOMMU. On systems without RAM above the 512GB boundary amd_iommu_quarantine_init() will setup page tables for the scratch page with 4 levels, while the IOMMU will be configured to use 3 levels only. The page destined to be used as level 1, and to contain a directory of PTEs ends up being the address in a PTE itself, and thus level 1 page becomes the leaf page. Without the level mismatch it's level 0 page that should be the leaf page instead. The level 1 page won't be used as such, and hence it's not possible to use it to gain access to other memory on the system. However that page is not cleared in amd_iommu_quarantine_init() as part of re-initialization of the device quarantine page tables, and hence data on the level 1 page can be leaked between device usages. Fix this by making sure the paging levels setup by amd_iommu_quarantine_init() match the number configured on the IOMMUs. Note that IVMD regions are not affected by this issue, as those areas are mapped taking the configured paging levels into account. This is XSA-445 / CVE-2023-46835 Fixes: ea38867831da ('x86 / iommu: set up a scratch page in the quarantine domain') Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- xen/drivers/passthrough/amd/iommu_map.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c index b4c182449131..3473db4c1efc 100644 --- xen/drivers/passthrough/amd/iommu_map.c.orig +++ xen/drivers/passthrough/amd/iommu_map.c @@@@ -584,9 +584,7 @@@@ static int fill_qpt(union amd_iommu_pte *this, unsigned int level, int amd_iommu_quarantine_init(struct pci_dev *pdev) { struct domain_iommu *hd = dom_iommu(dom_io); - unsigned long end_gfn = - 1ul << (DEFAULT_DOMAIN_ADDRESS_WIDTH - PAGE_SHIFT); - unsigned int level = amd_iommu_get_paging_mode(end_gfn); + unsigned int level = hd->arch.amd.paging_mode; unsigned int req_id = get_dma_requestor_id(pdev->seg, pdev->sbdf.bdf); const struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg); int rc; base-commit: 4a4daf6bddbe8a741329df5cc8768f7dec664aed -- 2.30.2 @