linux-kernel - Re: [PATCH v9 17/29] iommufd: Add mmap interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <db221336-2694-4fcf-a2b2-8fcb46ba3c9e@app.fastmail.com>
Date: Mon, 14 Jul 2025 08:08:21 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Nicolin Chen" <nicolinc@...dia.com>, "Jason Gunthorpe" <jgg@...dia.com>
Cc: "Kevin Tian" <kevin.tian@...el.com>, "Jonathan Corbet" <corbet@....net>,
 "Bagas Sanjaya" <bagasdotme@...il.com>, "Will Deacon" <will@...nel.org>,
 "Robin Murphy" <robin.murphy@....com>, "Joerg Roedel" <joro@...tes.org>,
 "Thierry Reding" <thierry.reding@...il.com>, vdumpa@...dia.com,
 "Jon Hunter" <jonathanh@...dia.com>, shuah <shuah@...nel.org>,
 jsnitsel@...hat.com, "Nathan Chancellor" <nathan@...nel.org>,
 "Peter Zijlstra" <peterz@...radead.org>, "Yi Liu" <yi.l.liu@...el.com>,
 mshavit@...gle.com, praan@...gle.com, zhangzekun11@...wei.com,
 iommu@...ts.linux.dev, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-tegra@...r.kernel.org, linux-kselftest@...r.kernel.org,
 patches@...ts.linux.dev, mochs@...dia.com,
 "ALOK TIWARI" <alok.a.tiwari@...cle.com>, vasant.hegde@....com,
 "David Woodhouse" <dwmw2@...radead.org>,
 "Baolu Lu" <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH v9 17/29] iommufd: Add mmap interface

On Thu, Jul 10, 2025, at 07:59, Nicolin Chen wrote:
>  EXPORT_SYMBOL_NS_GPL(_iommufd_object_undepend, "IOMMUFD");
> 
> +/*
> + * Allocate an @offset to return to user space to use for an mmap() 
> syscall
> + *
> + * Driver should use a per-structure helper in include/linux/iommufd.h
> + */
> +int _iommufd_alloc_mmap(struct iommufd_ctx *ictx, struct 
> iommufd_object *owner,
> +			phys_addr_t mmio_addr, size_t length,
> +			unsigned long *offset)
> +{
...
> +
> +	/* Skip the first page to ease caller identifying the returned offset 
> */
> +	rc = mtree_alloc_range(&ictx->mt_mmap, &startp, immap, immap->length,
> +			       PAGE_SIZE, PHYS_ADDR_MAX, GFP_KERNEL);


This produces a warning on 32-bit targets with a 64-bit phys_addr_t,
in practice this would be ARM Cortex-A15 or -A17 systems:

In file included from include/linux/overflow.h:6,
                 ...
                 from drivers/iommu/iommufd/driver.c:4:
drivers/iommu/iommufd/driver.c: In function '_iommufd_alloc_mmap':
include/linux/limits.h:11:25: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '18446744073709551615' to '4294967295' [-Werror=overflow]
   11 | #define PHYS_ADDR_MAX   (~(phys_addr_t)0)
      |                         ^~~~~~~~~~~~~~~~~
drivers/iommu/iommufd/driver.c:61:43: note: in expansion of macro 'PHYS_ADDR_MAX'
   61 |                                PAGE_SIZE, PHYS_ADDR_MAX, GFP_KERNEL);
      |                                           ^~~~~~~~~~~~~


The mtree_alloc_range() interface explicitly operates on 'unsigned long'
address values, so I don't see an immediate workaround for this that would
make it work on these machines. On the other hand, 

At the moment, the only drivers that select CONFIG_IOMMUFD_DRIVER
on 32-bit Arm systems are CONFIG_PDS_VFIO_PCI and CONFIG_MLX5_VFIO_PCI.
It's probably fine to make all three symbols "depends on 64BIT" for
now, but I don't know if there may be more drivers like this in the
future that actually could make sense on embedded systems.

     Arnd