Quoting Joonas Lahtinen (2018-06-15 09:08:54)
> Quoting Chris Wilson (2018-06-14 22:24:02)
> > If the user has created a read-only object, they should not be allowed
> > to circumvent the write protection by using a GGTT mmapping. Deny it.
> >
> > Also most machines do not support read-only GGTT PTEs, so again we have
> > to reject attempted writes. Fortunately, this is known a priori, so we
> > can at least reject in the call to create the mmap (with a sanity check
> > in the fault handler).
> >
> > v2: Check the vma->vm_flags during mmap() to allow readonly access.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Jon Bloomfield <jon.bloomfield@xxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> > Cc: Matthew Auld <matthew.william.auld@xxxxxxxxx>
> > Cc: David Herrmann <dh.herrmann@xxxxxxxxx>
> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> #v1
> > Reviewed-by: Matthew Auld <matthew.william.auld@xxxxxxxxx> #v1
> > Reviewed-by: Jon Bloomfield <jon.bloomfield@xxxxxxxxx>
>
> <SNIP>
>
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -1036,6 +1036,11 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> > return -EACCES;
> > }
> >
> > + if (vma->vm_flags & VM_WRITE && node->readonly) {
> > + drm_gem_object_put_unlocked(obj);
> > + return -EINVAL;
> > + }
> > +
>
> Pretty sure you want to split this patch and Cc: dri-devel. With that,
> both are:
I thought I cc'ed dri-devel on the previous sending. (At least I thought
about it.) Besides until ttm differentiates between read/write access,
it's a moot point.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
