Re: [PATCH kernel] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux