Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Thu, Feb 4, 2021 at 7:38 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
> > > > tldr; DMA buffers aren't normal memory, expecting that you can use
> > > > them like that (like calling get_user_pages works, or that they're
> > > > accounting like any other normal memory) cannot be guaranteed.
> > > >
> > > > Since some userspace only runs on integrated devices, where all
> > > > buffers are actually all resident system memory, there's a huge
> > > > temptation to assume that a struct page is always present and useable
> > > > like for any more pagecache backed mmap. This has the potential to
> > > > result in a uapi nightmare.
> > > >
> > > > To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which
> > > > blocks get_user_pages and all the other struct page based
> > > > infrastructure for everyone. In spirit this is the uapi counterpart to
> > > > the kernel-internal CONFIG_DMABUF_DEBUG.
> > >
> > > Fast gup needs the special flag set on the PTE as well.. Feels weird
> > > to have a special VMA without also having special PTEs?
> >
> > There's kinda no convenient & cheap way to check for the pte_special
> > flag. This here should at least catch accidental misuse, people
> > building their own ptes we can't stop. Maybe we should exclude
> > VM_MIXEDMAP to catch vm_insert_page in one of these.
> >
> > Hm looking at code I think we need to require VM_PFNMAP here to stop
> > vm_insert_page. And looking at the various functions, that seems to be
> > required (and I guess VM_IO is more for really funky architectures
> > where io-space is somewhere else?). I guess I should check for
> > VM_PFNMAP instead of VM_SPECIAL?
>
> Well, you said the goal was to block GUP usage, that won't happen
> without the PTE special flag, at least on x86
>
> So, really, what you are saying is all dmabuf users should always use
> vmf_insert_pfn_prot() or something similar - and never insert_page/etc?
>
> It might make sense to check the vma flags in all the insert paths, eg
> vm_insert_page() can't work with VMAs that should not have struct
> pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand
> it right)

Well that's what I've done, and it /looks/ like all the checks are
there already, as long as we use VM_PFNMAP. vm_insert_page tries to
auto-add VM_MIXEDMAP, but bails out with a BUG_ON if VM_PFNMAP is set.
And all the vm_insert_pfn_prot/remap_pfn_range functions require (or
set) VM_PFNMAP.

So I think just checking for VM_PFNMAP after the vma is set up should
be enough to guarantee we'll only have pte_special ptes in there,
ever. But I'm not sure, this stuff all isn't really documented much
and the code is sometimes a maze (to me at least).

> At least as some VM debug option

Seems to be there already unconditionally.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch