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

Alexey Kardashevskiy
2024-07-22T10:19:40Z

On 16/7/24 09:55, Jason Gunthorpe wrote:
> 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..

(uff, quite a thread, I am catching up)

Why flipping?

If there is vIOMMU, then the driver in the VM can decide whether it
wants private or shared memory for DMA, pass that new flag to dma_map()
and 1) have DMA memory allocated from the private pool (== no page state
changes) and 2) have C-bit set in the vIOMMU page table (which is in the
VM memory).

It is without vIOMMU when flipping is sort of a problem but the driver
in the VM can decide on type of DMA, talk to the TSM and only then
enable DMA (==bus master) but by then the things in the HV are settled
so we are ok.

Talking to the TSM does not really require DMA but even if it did, we
could enable untrusted DMA, do this attestation step, then disable DMA,
tell the HV/TSM to switch DMA to secure and enable DMA, all in the
driver's probe().

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

Hard to imagine why would a driver want this :)

> 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.

My V1 says "all IOVA below X are private and above - shared" (which is a
hw knob in absence of vIOMMU) and I set the X to all '1's just to mark
it all private.

>
> Jason

--
Alexey