On Wed, 7 Dec 2022 09:26:33 -0500
Steven Sistare <steven.sistare@xxxxxxxxxx> wrote:
> On 12/6/2022 6:52 PM, Alex Williamson wrote:
> > On Tue, 6 Dec 2022 13:55:46 -0800
> > Steve Sistare <steven.sistare@xxxxxxxxxx> wrote:
> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >> index d7d8e09..5c5cc7e 100644
> >> --- a/include/uapi/linux/vfio.h
> >> +++ b/include/uapi/linux/vfio.h
> > ...
> >> @@ -1265,18 +1256,12 @@ struct vfio_bitmap {
> >> *
> >> * If flags & VFIO_DMA_UNMAP_FLAG_ALL, unmap all addresses. iova and size
> >> * must be 0. This cannot be combined with the get-dirty-bitmap flag.
> >> - *
> >> - * If flags & VFIO_DMA_UNMAP_FLAG_VADDR, do not unmap, but invalidate host
> >> - * virtual addresses in the iova range. Tasks that attempt to translate an
> >> - * iova's vaddr will block. DMA to already-mapped pages continues. This
> >> - * cannot be combined with the get-dirty-bitmap flag.
> >> */
> >> struct vfio_iommu_type1_dma_unmap {
> >> __u32 argsz;
> >> __u32 flags;
> >> #define VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP (1 << 0)
> >> #define VFIO_DMA_UNMAP_FLAG_ALL (1 << 1)
> >> -#define VFIO_DMA_UNMAP_FLAG_VADDR (1 << 2)
> >
> >
> > This flag should probably be marked reserved.
> >
> > Should we consider this separately for v6.2?
>
> Ideally I would like all kernels to support either the old or new vaddr interface.
> If iommufd + vfio compat does not make 6.2, then I prefer not to delete the old
> interface separately.
You've identified a couple vulnerabilities with the current
implementation in the cover letter, userspace can detect the presence
of the feature and therefore removing it should only remove the
capability without breaking otherwise, no upstream userspace seems to
support this, and downstreams that wish to continue support can of
course revert the removal. So I think as far as the upstream kernel is
concerned, this is dead, risky code.
> > For the remainder, the long term plan is to move to iommufd, so any new
> > feature of type1 would need equivalent support in iommufd. Thanks,
>
> Sure. I will study iommufd and make a proposal.
>
> Will you review these patches as is to give feedback on the approach?
Yup, it's in my queue.
> If I show that iommufd and the vfio compat layer can support these interfaces,
> are you open to accepting these in v6.2 if iommufd is still a ways off? I see
> iommufd in qemu-next, but not the compat layer.
It's too late for this sort of feature for v6.2, the merge window is
only about 4 days way. I think the removal can be done with little
risk though. Thanks,
Alex
