[PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap

Daniel Vetter daniel at ffwll.ch
Wed Nov 20 12:34:56 UTC 2019


On Wed, Nov 20, 2019 at 1:18 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > > > I think for ttm just consistently using the one per-device mapping for
> > > > everything, with all the fake offsets, is probably the quickest route.
> > >
> > > Hmm, not clear how to fit dmabufs into this.  dmabufs already have their
> > > own file, inode and address space.  I'm not sure you can switch that
> > > over to the per-device mapping in the first place, and even if you can I
> > > have my doubts this is a good idea from a security point of view ...
> >
> > You can (plenty drivers do that already),
>
> Have pointer(s) to code?

dma_buf_mmap() does the same trick, but the other way round: It
converts from gem mapping and fake offset to dma-buf mapping and 0
offset. I think we'd simply need the inverse.

> > and not sure how that breaks
> > security?
>
> Go try mmap(fake-offset) on the dma-buf file handle to access other
> buffers of the drm device?  Hmm, thinking again, I guess the
> verify-access restrictions should prevent that.

Ah, we're not going to replace the mapping on the dma-buf file. Only
the file of the vma structure. Doing the former would indeed be pretty
bad from a security pov. So don't do what amdgpu_gem_prime_export
does, that's the bad stuff :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list