[PATCH kernel] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains
Alexey Kardashevskiy
aik at ozlabs.ru
Sat Jul 9 12:58:00 AEST 2022
On 08/07/2022 21:55, Jason Gunthorpe wrote:
> On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
>
>> For now I'll add a comment in spapr_tce_iommu_attach_dev() that it is fine
>> to do nothing as tce_iommu_take_ownership() and
>> tce_iommu_take_ownership_ddw() take care of not having active DMA mappings.
>
> That will still cause a security problem because
> tce_iommu_take_ownership()/etc are called too late. This is the moment
> in the flow when the ownershift must change away from the DMA API that
> power implements and to VFIO, not later.
Trying to do that.
vfio_group_set_container:
iommu_group_claim_dma_owner
driver->ops->attach_group
iommu_group_claim_dma_owner sets a domain to a group. Good. But it
attaches devices, not groups. Bad.
driver->ops->attach_group on POWER attaches a group so VFIO claims
ownership over a group, not devices. Underlying API
(pnv_ioda2_take_ownership()) does not need to keep track of the state,
it is one group, one ownership transfer, easy.
What is exactly the reason why iommu_group_claim_dma_owner() cannot stay
inside Type1 (sorry if it was explained, I could have missed)?
Also, from another mail, you said iommu_alloc_default_domain() should
fail on power but at least IOMMU_DOMAIN_BLOCKED must be supported, or
the whole iommu_group_claim_dma_owner() thing falls apart.
And iommu_ops::domain_alloc() is not told if it is asked to create a
default domain, it only takes a type.
--
Alexey
More information about the Linuxppc-dev
mailing list