On Fri, Dec 17, 2021 at 10:04:11PM +0100, David Hildenbrand wrote:
To remind all, the GUP users, like RDMA, VFIO use FOLL_FORCE|FOLL_WRITE to get a 'r/o pin' specifically because of the
I heard that statement often. Can you point me at the code?
VFIO: drivers/vfio/vfio_iommu_type1.c
vaddr_get_pfns() will end up doing a pin_user_pages_remote(FOLL_LONGTERM) without FOLL_FORCE|FOLL_WRITE.
Is that added automatically internally?
No, it is just that VFIO is broken in this regard. AFAIK VFIO users rarely use the read-only mode and haven't noticed this bug yet.
You can search for FOLL_FORCE and see the drivers that do it this way:
drivers/misc/habanalabs/common/memory.c: FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, drivers/infiniband/core/umem.c: gup_flags |= FOLL_FORCE; drivers/media/v4l2-core/videobuf-dma-sg.c: unsigned int flags = FOLL_FORCE; drivers/media/common/videobuf2/frame_vector.c: FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
[etc]
No doubt there are others that do it right and wrong, this is badly documented and misunderstood.
But this series really just wants to fix the security issue as "part 1". Without any more breakages.
Sure, I'm just trying to understand why this example was brought up.
Jason