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 backup in the
fault handler. This is a little draconian as we could blatantly ignore
the write protection on the pages, but it is far simply to keep the
readonly object pure. (It is easier to lift a restriction than to impose
it later!)
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfi...@intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Matthew Auld <matthew.william.a...@gmail.com>
---
drivers/gpu/drm/i915/i915_gem.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8dd4d35655af..d5eb73f7a90a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2009,6 +2009,10 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
unsigned int flags;
int ret;
+ /* Sanity check that we allow writing into this object */
+ if (obj->gt_ro && (write || !ggtt->vm.has_read_only))
+ return VM_FAULT_SIGBUS;
+
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
@@ -2288,10 +2292,17 @@ i915_gem_mmap_gtt(struct drm_file *file,
if (!obj)
return -ENOENT;
+ /* If we will not be able to create the GGTT vma, reject it early. */
+ if (obj->gt_ro && !to_i915(dev)->ggtt.vm.has_read_only) {
+ ret = -ENODEV;
+ goto out;
+ }
+
ret = i915_gem_object_create_mmap_offset(obj);
if (ret == 0)
*offset = drm_vma_node_offset_addr(&obj->base.vma_node);
+out:
i915_gem_object_put(obj);
return ret;
}
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
