On Thu, May 14, 2026 at 02:43:39PM +0000, Mostafa Saleh wrote: > > That's a somewhat different problem, we have the dev->trusted stuff > > that is supposed to deal with this kind of security. We need it for > > IOMMU based systems too, eg hot plug thunderbolt should have it. > > I see that it is used only for dma-iommu and for PCI devices. > However, I think that should be a problem with other CCA solutions > with emulated devices as they are untrusted. As I'd expect they > would have virtio devices.
Yes, any security solution with an out of TCB device should be using either memory encryption so the kernel already bounces or this trusted stuff and a force strict dma-iommu so the dma layer is careful. This is more policy from userspace what devices they want in or out of their TCB. Like you make accept the device into T=1 but then still want to keep it out of your TCB with the vIOMMU, I can see good arguments for something like that. > > > While we can debate the aesthetics of the setup , this is > > > the exisitng behaviour for Linux, which existed for years > > > and pKVM relies on and is used extensively. > > > And, this patch alters that long-standing logic and introduces > > > a functional regression. > > > > Yeah, Aneesh needs to do something here, I'm pointing out it is > > entirely seperate thing from the CC path we are working on which is > > decoupling CC from reylying on force swiotlb. > > I am looking into converting pKVM to use the CC stuff, I replied with > a patch to Aneesh in this thread. However, I need to do more testing > and make sure there are not any unwanted consequences. Yeah, it is a nice patch and I think it will help reduce the complexity if it aligns to CCA type stuff. > > In a pkvm world it should be the same, the S2 table for the SMMU will > > control what the device can access, and if the SMMU points to a > > "private" or "shared" page is not something the device needs to know > > or care about. > > I see that's because dma-iommu chooses the attrs for iommu_map(). Long term the DMA API path through the dma-iommu will pass the ATTR_CC_SHARED through to iommu_map so when the arch requires a different IOPTE it can construct it. > In pKVM, dma_addr_t and IOPTE are the same for private and shared, > so nothing differs in that case. Yes, so you don't have to worry. > We don’t expect pass-through devices to interact with shared > memory (T=0) at the moment. > However, I can see use cases for that, where the host and the guest > collaborate with device passthrough and require zero copy. Once you add the CC patch it becomes immediately possible though because the user can allocate a CC shared DMA HEAP and feed that all over the place. > One other interesting case for device-passthrough is non-coherent > devices which then require private pools for bouncing. Why does shared/private matter for bouncing? Why do you need to bounce at all? Do cmo's not work in pkvm guests? Jason
