Re: [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration

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

 



On Mon, Jul 15, 2024 at 04:37:01PM -0700, Dan Williams wrote:
> > So from a Linux VM perspective we have a PCI device with an IOMMU,
> > except that IOMMU flips into IDENTITY if T=0 is used.
> > 
> > From a driver model and DMA API this is totally nutzo :)
> > 
> > Being able to flip from trusted/untrusted and keep IOMMU/DMA/etc
> > unaffected requires that the vIOMMU can always walk the same IO page
> > tables stored in trusted VM memory, regardless if the device sends a
> > T=0/1 TLP.
> 
> "Keep IOMMU/DMA/etc unaffected" is the hard part.

Yes, but that is not just "unaffected" but it is implying that there
is state in the VM's iommu layer too. If T=0 goes to a different
translation then the DMA API must change behavior while a driver is
bound, which is not something we do today.

> Implementations that want something more complicated than that, like
> interleave T=0 and T=1 traffic, need to demonstrate how that is possible
> given the iommufd maintainer declares it, *checks notes*, "totally
> nutzo".

Oh we can make the iommufd side work out, it is the VM's kernel that
is going to be trouble :)

Even in the simpler case of no-interleave but the same driver will
start with T=0 and change to T=1 is pretty complex:

 dma_addr1 = dma_map()   <== Must return a bypass address because T=0
 goto_t_1()              <== Now dma_addr1 stops being usable
 dma_addr2 = dma_map()   <== Must return a translated address through the vIOMMU
 dma_unmap(dma_addr1)    <== Well now you've done it. Your kernel explodes.

Maybe the "violance" is we have to unbind the PCI driver and rebind it
to get the goto_t_1() effect..

Changing the underlying behavior of the DMA API "in flight" while a
driver is bound seems really dangerous.

My point is if we start baking in the assumption that drivers can do
things like the above without addressing how the VIOMMU integration
works we are going to have a *huge mess* to try and introduce VIOMMU
down the road.

I'd be happy if V1 forbade the above entirely.

Jason




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux