From: Jason Gunthorpe <jgg@nvidia.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
kevin.tian@intel.com, maz@kernel.org, joro@8bytes.org,
will@kernel.org, robin.murphy@arm.com, shuah@kernel.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org, eric.auger@redhat.com,
baolu.lu@linux.intel.com, yi.l.liu@intel.com,
yury.norov@gmail.com, jacob.pan@linux.microsoft.com,
patches@lists.linux.dev
Subject: Re: [PATCH v1 01/13] genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie
Date: Thu, 13 Feb 2025 09:57:52 -0400 [thread overview]
Message-ID: <20250213135752.GY3754072@nvidia.com> (raw)
In-Reply-To: <87y0yajc0o.ffs@tglx>
On Thu, Feb 13, 2025 at 12:54:15PM +0100, Thomas Gleixner wrote:
> So this change log really fails to follow the basic structure:
>
> The context, the problem and the solution
The IOMMU translation for MSI message addresses is a two step
process, seperated in time:
1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA
address is stored in the MSI descriptor, when a MSI interrupt is
allocated.
2) iommu_dma_compose_msi_msg(): The compose callback uses this
cookkie pointer to compute the translated message address.
This has an inherent lifetime problem for the pointer stored in the
cookie. It must remain valid between the two steps. There is no
locking at the irq layer that helps protect the liftime. Today this
only works under the assumption that the iommu domain is not changed
while MSI interrupts are being programmed. This is true for normal DMA
API users within the kernel as the iommu domain is attached before the
driver is probed and cannot be changed while a driver is attached.
Classic VFIO type1 also prevented changing the iommu domain while VFIO
was running as it does not support changing the "container" after
starting up.
However, iommufd has improved this and we can change the iommu domain
during VFIO operation. This allows userspace to directly race
VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and
VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).
This causes both the cookie pointer and the unlocked call to
iommu_get_domain_for_dev() on the MSI translation path to become a
potential UAF.
Fix the MSI cookie UAF by removing the cookie pointer. The translated
message address is already known during iommu_dma_prepare_msi() and
can not change. It can simply be stored as an integer in the MSI
descriptor.
A following patch will correct the iommu_get_domain_for_dev() UAF
using the IOMMU group mutex.
Ok?
Nicolin - lets change the patch structure a little bit can you adjust
this patch to leave iommu_dma_compose_msi_msg() in dma-iommu.c and the
next patch will be all about renaming and moving it to the MSI core
code instead? Easier to explain
Thanks,
Jason
next prev parent reply other threads:[~2025-02-13 13:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-08 9:02 [PATCH v1 00/13] iommu: Add MSI mapping support with nested SMMU Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 01/13] genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie Nicolin Chen
2025-02-13 11:54 ` Thomas Gleixner
2025-02-13 13:57 ` Jason Gunthorpe [this message]
2025-02-13 21:34 ` Nicolin Chen
2025-02-13 20:28 ` Jacob Pan
2025-02-13 21:02 ` Nicolin Chen
2025-02-13 21:33 ` Jacob Pan
2025-02-08 9:02 ` [PATCH v1 02/13] genirq/msi: Rename iommu_dma_compose_msi_msg() to msi_msg_set_addr() Nicolin Chen
2025-02-13 12:11 ` Thomas Gleixner
2025-02-13 14:37 ` Jason Gunthorpe
2025-02-08 9:02 ` [PATCH v1 03/13] iommu: Make iommu_dma_prepare_msi() into a generic operation Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 04/13] irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by the irqchips that need it Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 05/13] iommu: Turn fault_data to iommufd private pointer Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 06/13] iommufd: Implement sw_msi support natively Nicolin Chen
2025-02-11 18:16 ` Jason Gunthorpe
2025-02-11 19:04 ` Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 07/13] iommu: Turn iova_cookie to dma-iommu private pointer Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 08/13] iommufd/device: Move sw_msi_start from igroup to idev Nicolin Chen
2025-02-09 18:41 ` Jason Gunthorpe
2025-02-10 23:25 ` Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 09/13] iommufd: Pass in idev to iopt_table_enforce_dev_resv_regions Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 10/13] iommufd: Add IOMMU_OPTION_SW_MSI_START/SIZE ioctls Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 11/13] iommufd/selftest: Add MOCK_FLAGS_DEVICE_NO_ATTACH Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 12/13] iommufd/selftest: Add a testing reserved region Nicolin Chen
2025-02-08 9:02 ` [PATCH v1 13/13] iommufd/selftest: Add coverage for IOMMU_OPTION_SW_MSI_START/SIZE Nicolin Chen
2025-02-19 13:37 ` [PATCH v1 00/13] iommu: Add MSI mapping support with nested SMMU Jason Gunthorpe
2025-02-19 16:06 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250213135752.GY3754072@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.pan@linux.microsoft.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maz@kernel.org \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox