What it looks like to me is abusing SWIOTLB's internal housekeeping to
keep track of virtio-specific state. The DMA API does not attempt to
validate calls in general since in many cases the additional overhead
would be prohibitive. It has always been callers' responsibility to
keep track of what they mapped and make sure sync/unmap calls match,
and there are many, many, subtle and not-so-subtle ways for things to
go wrong if they don't. If virtio is not doing a good enough job of
that, what's the justification for making it the DMA API's problem?
In this case it's not prohibitive at all. Just adding a few error
returns, and checking the overlap (which seems to have been already
solved anyways) I would argue the error returns are good practice
anyways, so that API users can check that something bad happening and
abort. The DMA API was never very good at proper error handling, but
there's no reason at all to continue being bad it forever.
AFAIK the rest just works anyways, so it's not really a new problem to
be solved.
A new callback is used to avoid changing all the IOMMU drivers.
Nit: presumably by "IOMMU drivers" you actually mean arch DMA API
backends?
Yes
Furthermore, AFAICS it's still not going to help against exfiltrating
guest memory by over-unmapping the original SWIOTLB slot *without*
going past the end of the whole buffer,
That would be just exfiltrating data that is already shared, unless I'm
misunderstanding you.
-Andi
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
