[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] arm/acpi: don't expose the ACPI IORT SMMUv3 entry to dom0
On 2022-04-27 17:12, Rahul Singh wrote: Xen should control the SMMUv3 devices therefore, don't expose the SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for dom0 and also make ACPI IORT SMMUv3 node type to 0xff. ...making the resulting IORT technically useless to consumers. ID mappings for all the Root Complex, Named Component and RMR nodes which were supposed to be translated through that SMMU node are now invalid, because ID mappings can only target an SMMU or ITS node. I can't guess at how other consumers may react, but Linux's IORT code is going to experience undefined behaviour when tries to translate any MSI DeviceID mappings through this invalid node, since it uses a bitmap of (1 << node->type) internally; beyond that we're not as strict as we could be and make some pretty loose assumptions about what we're parsing, so it might even appear to work, but that could easily change at any time in future and is absolutely not something Xen or any other software should try to rely on. Thanks, Robin. Signed-off-by: Rahul Singh <rahul.singh@xxxxxxx> --- xen/arch/arm/acpi/domain_build.c | 40 ++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c index bbdc90f92c..ec0b5b261f 100644 --- a/xen/arch/arm/acpi/domain_build.c +++ b/xen/arch/arm/acpi/domain_build.c @@ -14,6 +14,7 @@ #include <xen/acpi.h> #include <xen/event.h> #include <xen/iocap.h> +#include <xen/sizes.h> #include <xen/device_tree.h> #include <xen/libfdt/libfdt.h> #include <acpi/actables.h> @@ -30,6 +31,7 @@ static int __init acpi_iomem_deny_access(struct domain *d) { acpi_status status; struct acpi_table_spcr *spcr = NULL; + struct acpi_table_iort *iort; unsigned long mfn; int rc;@@ -55,6 +57,44 @@ static int __init acpi_iomem_deny_access(struct domain *d)printk("Failed to get SPCR table, Xen console may be unavailable\n"); }+ status = acpi_get_table(ACPI_SIG_IORT, 0,+ (struct acpi_table_header **)&iort); + + if ( ACPI_SUCCESS(status) ) + { + int i; + struct acpi_iort_node *node, *end; + node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset); + end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length); + + for ( i = 0; i < iort->node_count; i++ ) + { + if ( node >= end ) + break; + + switch ( node->type ) + { + case ACPI_IORT_NODE_SMMU_V3: + { + struct acpi_iort_smmu_v3 *smmu; + smmu = (struct acpi_iort_smmu_v3 *)node->node_data; + mfn = paddr_to_pfn(smmu->base_address); + rc = iomem_deny_access(d, mfn, mfn + PFN_UP(SZ_128K)); + if ( rc ) + printk("iomem_deny_access failed for SMMUv3\n"); + node->type = 0xff; + break; + } + } + node = ACPI_ADD_PTR(struct acpi_iort_node, node, node->length); + } + } + else + { + printk("Failed to get IORT table\n"); + return -EINVAL; + } + /* Deny MMIO access for GIC regions */ return gic_iomem_deny_access(d); }
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |