* [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
@ 2018-06-14 11:59 Chris Wilson
2018-06-14 11:59 ` [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+ Chris Wilson
` (5 more replies)
0 siblings, 6 replies; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 11:59 UTC (permalink / raw)
To: intel-gfx
From: Jon Bloomfield <jon.bloomfield@intel.com>
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8a51dd4d191a..f307861c3374 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -236,10 +236,13 @@ static void clear_pages(struct i915_vma *vma)
}
static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
- enum i915_cache_level level)
+ enum i915_cache_level level,
+ u32 flags)
{
- gen8_pte_t pte = _PAGE_PRESENT | _PAGE_RW;
- pte |= addr;
+ gen8_pte_t pte = addr | _PAGE_PRESENT | _PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~_PAGE_RW;
switch (level) {
case I915_CACHE_NONE:
@@ -629,7 +632,7 @@ static void gen8_initialize_pt(struct i915_address_space *vm,
struct i915_page_table *pt)
{
fill_px(vm, pt,
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC));
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0));
}
static void gen6_initialize_pt(struct gen6_hw_ppgtt *ppgtt,
@@ -777,7 +780,7 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space *vm,
unsigned int pte = gen8_pte_index(start);
unsigned int pte_end = pte + num_entries;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t *vaddr;
GEM_BUG_ON(num_entries > pt->used_ptes);
@@ -952,7 +955,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
enum i915_cache_level cache_level)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
gen8_pte_t *vaddr;
bool ret;
@@ -1020,7 +1023,7 @@ static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct sgt_dma *iter,
enum i915_cache_level cache_level)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1486,7 +1489,7 @@ static void gen8_dump_ppgtt(struct i915_hw_ppgtt *ppgtt, struct seq_file *m)
{
struct i915_address_space *vm = &ppgtt->vm;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
u64 start = 0, length = ppgtt->vm.total;
if (use_4lvl(vm)) {
@@ -2390,7 +2393,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
- gen8_set_pte(pte, gen8_pte_encode(addr, level));
+ gen8_set_pte(pte, gen8_pte_encode(addr, level, 0));
ggtt->invalidate(vm->i915);
}
@@ -2403,7 +2406,7 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
gen8_pte_t __iomem *gtt_entries;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
@@ -2471,7 +2474,7 @@ static void gen8_ggtt_clear_range(struct i915_address_space *vm,
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t __iomem *gtt_base =
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
@ 2018-06-14 11:59 ` Chris Wilson
2018-06-14 11:59 ` [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap Chris Wilson
` (4 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 11:59 UTC (permalink / raw)
To: intel-gfx
From: Jon Bloomfield <jon.bloomfield@intel.com>
Hook up the flags to allow read-only ppGTT mappings for gen8+
v2: Include a selftest to check that writes to a readonly PTE are
dropped
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 ++++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 7 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 138 ++++++++++++++++++
4 files changed, 182 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f307861c3374..ca84616fbe24 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -196,7 +196,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
return err;
}
- /* Currently applicable only to VLV */
+ /* Applicable to VLV, and gen8+ */
pte_flags = 0;
if (vma->obj->gt_ro)
pte_flags |= PTE_READ_ONLY;
@@ -952,10 +952,11 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
struct i915_page_directory_pointer *pdp,
struct sgt_dma *iter,
struct gen8_insert_pte *idx,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
gen8_pte_t *vaddr;
bool ret;
@@ -1006,14 +1007,14 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
gen8_ppgtt_insert_pte_entries(ppgtt, &ppgtt->pdp, &iter, &idx,
- cache_level);
+ cache_level, flags);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
}
@@ -1021,9 +1022,10 @@ static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct i915_page_directory_pointer **pdps,
struct sgt_dma *iter,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1139,19 +1141,21 @@ static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge_entries(vma, pdps, &iter, cache_level);
+ gen8_ppgtt_insert_huge_entries(vma, pdps, &iter, cache_level,
+ flags);
} else {
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++],
- &iter, &idx, cache_level))
+ &iter, &idx, cache_level,
+ flags))
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
@@ -1564,6 +1568,9 @@ static struct i915_hw_ppgtt *gen8_ppgtt_create(struct drm_i915_private *i915)
1ULL << 48 :
1ULL << 32;
+ /* From bdw, there is support for read-only pages in the PPGTT */
+ ppgtt->vm.has_read_only = true;
+
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
*/
@@ -2401,7 +2408,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space *vm,
static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level level,
- u32 unused)
+ u32 flags)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
@@ -2409,6 +2416,9 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
+ /* The GTT does not support read-only mappings */
+ GEM_BUG_ON(flags & PTE_READ_ONLY);
+
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
gtt_entries += vma->node.start >> PAGE_SHIFT;
for_each_sgt_dma(addr, sgt_iter, vma->pages)
@@ -2535,13 +2545,14 @@ struct insert_entries {
struct i915_address_space *vm;
struct i915_vma *vma;
enum i915_cache_level level;
+ u32 flags;
};
static int bxt_vtd_ggtt_insert_entries__cb(void *_arg)
{
struct insert_entries *arg = _arg;
- gen8_ggtt_insert_entries(arg->vm, arg->vma, arg->level, 0);
+ gen8_ggtt_insert_entries(arg->vm, arg->vma, arg->level, arg->flags);
bxt_vtd_ggtt_wa(arg->vm);
return 0;
@@ -2550,9 +2561,9 @@ static int bxt_vtd_ggtt_insert_entries__cb(void *_arg)
static void bxt_vtd_ggtt_insert_entries__BKL(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level level,
- u32 unused)
+ u32 flags)
{
- struct insert_entries arg = { vm, vma, level };
+ struct insert_entries arg = { vm, vma, level, flags };
stop_machine(bxt_vtd_ggtt_insert_entries__cb, &arg, NULL);
}
@@ -2643,7 +2654,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
struct drm_i915_gem_object *obj = vma->obj;
u32 pte_flags;
- /* Currently applicable only to VLV */
+ /* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
if (obj->gt_ro)
pte_flags |= PTE_READ_ONLY;
@@ -3525,6 +3536,10 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
*/
mutex_lock(&dev_priv->drm.struct_mutex);
i915_address_space_init(&ggtt->vm, dev_priv, "[global]");
+
+ /* Only VLV supports read-only GGTT mappings */
+ ggtt->vm.has_read_only = IS_VALLEYVIEW(dev_priv);
+
if (!HAS_LLC(dev_priv) && !USES_PPGTT(dev_priv))
ggtt->vm.mm.color_adjust = i915_gtt_color_adjust;
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 4f6f4595c9e9..9de37dcaa5ab 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -325,7 +325,12 @@ struct i915_address_space {
struct list_head unbound_list;
struct pagevec free_pages;
- bool pt_kmap_wc;
+
+ /* Some systems require uncached updates of the page directories */
+ bool pt_kmap_wc:1;
+
+ /* Some systems support read-only mappings for GGTT and/or PPGTT */
+ bool has_read_only:1;
/* FIXME: Need a more generic return type */
gen6_pte_t (*pte_encode)(dma_addr_t addr,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ef3c76425843..8853a5e6d421 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1097,6 +1097,7 @@ void intel_ring_unpin(struct intel_ring *ring)
static struct i915_vma *
intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
{
+ struct i915_address_space *vm = &dev_priv->ggtt.vm;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -1106,10 +1107,14 @@ intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
if (IS_ERR(obj))
return ERR_CAST(obj);
- /* mark ring buffers as read-only from GPU side by default */
- obj->gt_ro = 1;
+ /*
+ * Mark ring buffers as read-only from GPU side (so no stray overwrites)
+ * if supported by the platform's GGTT.
+ */
+ if (vm->has_read_only)
+ obj->gt_ro = 1;
- vma = i915_vma_instance(obj, &dev_priv->ggtt.vm, NULL);
+ vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
goto err;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 836f1af8b833..5bae52068926 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -23,6 +23,7 @@
*/
#include "../i915_selftest.h"
+#include "i915_random.h"
#include "igt_flush_test.h"
#include "mock_drm.h"
@@ -266,6 +267,41 @@ static int cpu_check(struct drm_i915_gem_object *obj, unsigned int max)
return err;
}
+static int ro_check(struct drm_i915_gem_object *obj, unsigned int max)
+{
+ unsigned int n, m, needs_flush;
+ int err;
+
+ err = i915_gem_obj_prepare_shmem_read(obj, &needs_flush);
+ if (err)
+ return err;
+
+ for (n = 0; n < real_page_count(obj); n++) {
+ u32 *map;
+
+ map = kmap_atomic(i915_gem_object_get_page(obj, n));
+ if (needs_flush & CLFLUSH_BEFORE)
+ drm_clflush_virt_range(map, PAGE_SIZE);
+
+ for (m = 0; m < DW_PER_PAGE; m++) {
+ if (map[m] != 0xdeadbeef) {
+ pr_err("Invalid value (overwritten) at page %d, offset %d: found %08x expected %08x\n",
+ n, m, map[m], 0xdeadbeef);
+ err = -EINVAL;
+ goto out_unmap;
+ }
+ }
+
+out_unmap:
+ kunmap_atomic(map);
+ if (err)
+ break;
+ }
+
+ i915_gem_obj_finish_shmem_access(obj);
+ return err;
+}
+
static int file_add_object(struct drm_file *file,
struct drm_i915_gem_object *obj)
{
@@ -421,6 +457,107 @@ static int igt_ctx_exec(void *arg)
return err;
}
+static int igt_ctx_readonly(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj = NULL;
+ struct drm_file *file;
+ I915_RND_STATE(prng);
+ IGT_TIMEOUT(end_time);
+ LIST_HEAD(objects);
+ struct i915_gem_context *ctx;
+ struct i915_hw_ppgtt *ppgtt;
+ unsigned long ndwords, dw;
+ int err = -ENODEV;
+
+ /* Create a few different contexts (with different mm) and write
+ * through each ctx/mm using the GPU making sure those writes end
+ * up in the expected pages of our obj.
+ */
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(&i915->drm.struct_mutex);
+
+ ctx = i915_gem_create_context(i915, file->driver_priv);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out_unlock;
+ }
+
+ ppgtt = ctx->ppgtt ?: i915->mm.aliasing_ppgtt;
+ if (!ppgtt || !ppgtt->vm.has_read_only) {
+ err = 0;
+ goto out_unlock;
+ }
+
+ ndwords = 0;
+ dw = 0;
+ while (!time_after(jiffies, end_time)) {
+ struct intel_engine_cs *engine;
+ unsigned int id;
+
+ for_each_engine(engine, i915, id) {
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (!obj) {
+ obj = create_test_object(ctx, file, &objects);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ goto out_unlock;
+ }
+
+ obj->gt_ro = prandom_u32_state(&prng);
+ }
+
+ intel_runtime_pm_get(i915);
+ err = gpu_fill(obj, ctx, engine, dw);
+ intel_runtime_pm_put(i915);
+ if (err) {
+ pr_err("Failed to fill dword %lu [%lu/%lu] with gpu (%s) in ctx %u [full-ppgtt? %s], err=%d\n",
+ ndwords, dw, max_dwords(obj),
+ engine->name, ctx->hw_id,
+ yesno(!!ctx->ppgtt), err);
+ goto out_unlock;
+ }
+
+ if (++dw == max_dwords(obj)) {
+ obj = NULL;
+ dw = 0;
+ }
+ ndwords++;
+ }
+ }
+ pr_info("Submitted %lu dwords (across %u engines)\n",
+ ndwords, INTEL_INFO(i915)->num_rings);
+
+ dw = 0;
+ list_for_each_entry(obj, &objects, st_link) {
+ unsigned int rem =
+ min_t(unsigned int, ndwords - dw, max_dwords(obj));
+
+ if (obj->gt_ro)
+ err = ro_check(obj, rem);
+ else
+ err = cpu_check(obj, rem);
+ if (err)
+ break;
+
+ dw += rem;
+ }
+
+out_unlock:
+ if (igt_flush_test(i915, I915_WAIT_LOCKED))
+ err = -EIO;
+ mutex_unlock(&i915->drm.struct_mutex);
+
+ mock_file_free(i915, file);
+ return err;
+}
+
static __maybe_unused const char *
__engine_name(struct drm_i915_private *i915, unsigned int engines)
{
@@ -595,6 +732,7 @@ int i915_gem_context_live_selftests(struct drm_i915_private *dev_priv)
static const struct i915_subtest tests[] = {
SUBTEST(igt_switch_to_kernel_context),
SUBTEST(igt_ctx_exec),
+ SUBTEST(igt_ctx_readonly),
};
bool fake_alias = false;
int err;
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
2018-06-14 11:59 ` [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+ Chris Wilson
@ 2018-06-14 11:59 ` Chris Wilson
2018-06-14 14:53 ` Bloomfield, Jon
2018-06-14 16:06 ` [PATCH v2] " Chris Wilson
2018-06-14 11:59 ` [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object Chris Wilson
` (3 subsequent siblings)
5 siblings, 2 replies; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 11:59 UTC (permalink / raw)
To: intel-gfx
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 <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 11:59 ` [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap Chris Wilson
@ 2018-06-14 14:53 ` Bloomfield, Jon
2018-06-14 15:00 ` Chris Wilson
2018-06-14 16:06 ` [PATCH v2] " Chris Wilson
1 sibling, 1 reply; 21+ messages in thread
From: Bloomfield, Jon @ 2018-06-14 14:53 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, June 14, 2018 5:00 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> <jon.bloomfield@intel.com>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>; Matthew Auld
> <matthew.william.auld@gmail.com>
> Subject: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a
> GGTT mmap
>
> 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!)
Are you sure this is necessary? I assumed you would just create a ro IA
mapping to the page, irrespective of the ability of ggtt. It feels wrong to
disallow mapping a read-only object to the CPU as read-only. With ppgtt
the presence of an unprotected mapping in the ggtt should be immune
from tampering in the GT, so only the cpu mapping should really matter.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Matthew Auld <matthew.william.auld@gmail.com>
> ---
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 14:53 ` Bloomfield, Jon
@ 2018-06-14 15:00 ` Chris Wilson
2018-06-14 15:06 ` Bloomfield, Jon
0 siblings, 1 reply; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 15:00 UTC (permalink / raw)
To: Bloomfield, Jon, intel-gfx
Quoting Bloomfield, Jon (2018-06-14 15:53:13)
> > -----Original Message-----
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> > Sent: Thursday, June 14, 2018 5:00 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> > <jon.bloomfield@intel.com>; Joonas Lahtinen
> > <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > <matthew.william.auld@gmail.com>
> > Subject: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a
> > GGTT mmap
> >
> > 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!)
> Are you sure this is necessary? I assumed you would just create a ro IA
> mapping to the page, irrespective of the ability of ggtt.
You are thinking of the CPU mmap? The GTT mmap offers a linear view of
the tiled object. It would be very wrong for us to bypass the PROT_READ
protection of a user page by accessing it via the GTT.
> It feels wrong to
> disallow mapping a read-only object to the CPU as read-only. With ppgtt
> the presence of an unprotected mapping in the ggtt should be immune
> from tampering in the GT, so only the cpu mapping should really matter.
And the CPU mapping has its protection bits on the IA PTE.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 15:00 ` Chris Wilson
@ 2018-06-14 15:06 ` Bloomfield, Jon
2018-06-14 15:21 ` Chris Wilson
0 siblings, 1 reply; 21+ messages in thread
From: Bloomfield, Jon @ 2018-06-14 15:06 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, June 14, 2018 8:00 AM
> To: Bloomfield, Jon <jon.bloomfield@intel.com>; intel-
> gfx@lists.freedesktop.org
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>; Matthew Auld
> <matthew.william.auld@gmail.com>
> Subject: RE: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via
> a GGTT mmap
>
> Quoting Bloomfield, Jon (2018-06-14 15:53:13)
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Thursday, June 14, 2018 5:00 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> > > <jon.bloomfield@intel.com>; Joonas Lahtinen
> > > <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > > <matthew.william.auld@gmail.com>
> > > Subject: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via
> a
> > > GGTT mmap
> > >
> > > 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!)
> > Are you sure this is necessary? I assumed you would just create a ro IA
> > mapping to the page, irrespective of the ability of ggtt.
>
> You are thinking of the CPU mmap? The GTT mmap offers a linear view of
> the tiled object. It would be very wrong for us to bypass the PROT_READ
> protection of a user page by accessing it via the GTT.
No, I was thinking of gtt mmap. That requires both GTT and IA PTE mappings
right? One to map the object into the GTT, and then a second to point the
IA at the aperture. Why wouldn't marking the IA mapping RO protect the
object if the GT cannot reach the GTT mapping (from user batches).
>
> > It feels wrong to
> > disallow mapping a read-only object to the CPU as read-only. With ppgtt
> > the presence of an unprotected mapping in the ggtt should be immune
> > from tampering in the GT, so only the cpu mapping should really matter.
>
> And the CPU mapping has its protection bits on the IA PTE.
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 15:06 ` Bloomfield, Jon
@ 2018-06-14 15:21 ` Chris Wilson
2018-06-14 15:33 ` Bloomfield, Jon
0 siblings, 1 reply; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 15:21 UTC (permalink / raw)
To: Bloomfield, Jon, intel-gfx
Quoting Bloomfield, Jon (2018-06-14 16:06:40)
> > -----Original Message-----
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> > Sent: Thursday, June 14, 2018 8:00 AM
> > To: Bloomfield, Jon <jon.bloomfield@intel.com>; intel-
> > gfx@lists.freedesktop.org
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > <matthew.william.auld@gmail.com>
> > Subject: RE: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via
> > a GGTT mmap
> >
> > Quoting Bloomfield, Jon (2018-06-14 15:53:13)
> > > > -----Original Message-----
> > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Sent: Thursday, June 14, 2018 5:00 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> > > > <jon.bloomfield@intel.com>; Joonas Lahtinen
> > > > <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > > > <matthew.william.auld@gmail.com>
> > > > Subject: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via
> > a
> > > > GGTT mmap
> > > >
> > > > 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!)
> > > Are you sure this is necessary? I assumed you would just create a ro IA
> > > mapping to the page, irrespective of the ability of ggtt.
> >
> > You are thinking of the CPU mmap? The GTT mmap offers a linear view of
> > the tiled object. It would be very wrong for us to bypass the PROT_READ
> > protection of a user page by accessing it via the GTT.
> No, I was thinking of gtt mmap. That requires both GTT and IA PTE mappings
> right? One to map the object into the GTT, and then a second to point the
> IA at the aperture. Why wouldn't marking the IA mapping RO protect the
> object if the GT cannot reach the GTT mapping (from user batches).
Hmm. I keep forgetting that we can get at the vma from mmap(), because
that's hidden away elsewhere and only see i915_gem_fault() on a daily
basis. Hmm, is legal to read a PROT_READ-only vma is PROT_WRITE is
requested, or are meant to return -EINVAL?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 15:21 ` Chris Wilson
@ 2018-06-14 15:33 ` Bloomfield, Jon
0 siblings, 0 replies; 21+ messages in thread
From: Bloomfield, Jon @ 2018-06-14 15:33 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, June 14, 2018 8:22 AM
> To: Bloomfield, Jon <jon.bloomfield@intel.com>; intel-
> gfx@lists.freedesktop.org
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>; Matthew Auld
> <matthew.william.auld@gmail.com>
> Subject: RE: [PATCH 3/5] drm/i915: Prevent writing into a read-only object via
> a GGTT mmap
>
> Quoting Bloomfield, Jon (2018-06-14 16:06:40)
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Thursday, June 14, 2018 8:00 AM
> > > To: Bloomfield, Jon <jon.bloomfield@intel.com>; intel-
> > > gfx@lists.freedesktop.org
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > > <matthew.william.auld@gmail.com>
> > > Subject: RE: [PATCH 3/5] drm/i915: Prevent writing into a read-only
> object via
> > > a GGTT mmap
> > >
> > > Quoting Bloomfield, Jon (2018-06-14 15:53:13)
> > > > > -----Original Message-----
> > > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Sent: Thursday, June 14, 2018 5:00 AM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> > > > > <jon.bloomfield@intel.com>; Joonas Lahtinen
> > > > > <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > > > > <matthew.william.auld@gmail.com>
> > > > > Subject: [PATCH 3/5] drm/i915: Prevent writing into a read-only
> object via
> > > a
> > > > > GGTT mmap
> > > > >
> > > > > 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!)
> > > > Are you sure this is necessary? I assumed you would just create a ro IA
> > > > mapping to the page, irrespective of the ability of ggtt.
> > >
> > > You are thinking of the CPU mmap? The GTT mmap offers a linear view of
> > > the tiled object. It would be very wrong for us to bypass the PROT_READ
> > > protection of a user page by accessing it via the GTT.
> > No, I was thinking of gtt mmap. That requires both GTT and IA PTE
> mappings
> > right? One to map the object into the GTT, and then a second to point the
> > IA at the aperture. Why wouldn't marking the IA mapping RO protect the
> > object if the GT cannot reach the GTT mapping (from user batches).
>
> Hmm. I keep forgetting that we can get at the vma from mmap(), because
> that's hidden away elsewhere and only see i915_gem_fault() on a daily
> basis. Hmm, is legal to read a PROT_READ-only vma is PROT_WRITE is
> requested, or are meant to return -EINVAL?
> -Chris
That's a trickier question :-) My instinct in -EINVAL if the user specifies
PROT_WRITE, but allowed if they only PROT_READ, and ppgtt is enabled
(including aliased) so that userspace can't see the gtt mapping from the GT.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 11:59 ` [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap Chris Wilson
2018-06-14 14:53 ` Bloomfield, Jon
@ 2018-06-14 16:06 ` Chris Wilson
2018-06-14 16:36 ` Bloomfield, Jon
1 sibling, 1 reply; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 16:06 UTC (permalink / raw)
To: intel-gfx; +Cc: Matthew Auld, dri-devel, Jon Bloomfield
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@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
drivers/gpu/drm/drm_gem.c | 5 +++++
drivers/gpu/drm/i915/i915_gem.c | 4 ++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++++++-----
drivers/gpu/drm/i915/i915_gem_object.h | 7 ++++++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 5 +++--
include/drm/drm_vma_manager.h | 1 +
7 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4a16d7b26c89..230863813905 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ 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;
+ }
+
ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT,
vma);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8dd4d35655af..2bfb16e83af2 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 (i915_gem_object_is_readonly(obj) && write)
+ 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;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ca84616fbe24..d57f0154b6cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -198,7 +198,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
/* Applicable to VLV, and gen8+ */
pte_flags = 0;
- if (vma->obj->gt_ro)
+ if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
@@ -2416,8 +2416,10 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
- /* The GTT does not support read-only mappings */
- GEM_BUG_ON(flags & PTE_READ_ONLY);
+ /*
+ * Note that we ignore PTE_READ_ONLY here. The caller must be careful
+ * not to allow the user to override access to a read only page.
+ */
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
gtt_entries += vma->node.start >> PAGE_SHIFT;
@@ -2656,7 +2658,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
- if (obj->gt_ro)
+ if (i915_gem_object_is_readonly(obj))
pte_flags |= PTE_READ_ONLY;
intel_runtime_pm_get(i915);
@@ -2694,7 +2696,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
/* Currently applicable only to VLV */
pte_flags = 0;
- if (vma->obj->gt_ro)
+ if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
if (flags & I915_VMA_LOCAL_BIND) {
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h
index 54f00b350779..66e30aa4b7da 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -141,7 +141,6 @@ struct drm_i915_gem_object {
* Is the object to be mapped as read-only to the GPU
* Only honoured if hardware has relevant pte bit
*/
- unsigned long gt_ro:1;
unsigned int cache_level:3;
unsigned int cache_coherent:2;
#define I915_BO_CACHE_COHERENT_FOR_READ BIT(0)
@@ -367,6 +366,12 @@ static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
reservation_object_unlock(obj->resv);
}
+static inline bool
+i915_gem_object_is_readonly(const struct drm_i915_gem_object *obj)
+{
+ return obj->base.vma_node.readonly;
+}
+
static inline bool
i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8853a5e6d421..d18033bc65df 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1112,7 +1112,7 @@ intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
* if supported by the platform's GGTT.
*/
if (vm->has_read_only)
- obj->gt_ro = 1;
+ obj->base.vma_node.readonly = true;
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 5bae52068926..c02c4940c013 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -510,7 +510,8 @@ static int igt_ctx_readonly(void *arg)
goto out_unlock;
}
- obj->gt_ro = prandom_u32_state(&prng);
+ if (prandom_u32_state(&prng) & 1)
+ obj->base.vma_node.readonly = true;
}
intel_runtime_pm_get(i915);
@@ -539,7 +540,7 @@ static int igt_ctx_readonly(void *arg)
unsigned int rem =
min_t(unsigned int, ndwords - dw, max_dwords(obj));
- if (obj->gt_ro)
+ if (i915_gem_object_is_readonly(obj))
err = ro_check(obj, rem);
else
err = cpu_check(obj, rem);
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 8758df94e9a0..c7987daeaed0 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -41,6 +41,7 @@ struct drm_vma_offset_node {
rwlock_t vm_lock;
struct drm_mm_node vm_node;
struct rb_root vm_files;
+ bool readonly:1;
};
struct drm_vma_offset_manager {
--
2.17.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 16:06 ` [PATCH v2] " Chris Wilson
@ 2018-06-14 16:36 ` Bloomfield, Jon
2018-06-14 16:48 ` Chris Wilson
0 siblings, 1 reply; 21+ messages in thread
From: Bloomfield, Jon @ 2018-06-14 16:36 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: dri-devel, David Herrmann
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, June 14, 2018 9:07 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Chris Wilson <chris@chris-wilson.co.uk>;
> Bloomfield, Jon <jon.bloomfield@intel.com>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>; Matthew Auld
> <matthew.william.auld@gmail.com>; David Herrmann
> <dh.herrmann@gmail.com>
> Subject: [PATCH v2] drm/i915: Prevent writing into a read-only object via a
> GGTT mmap
>
> 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@chris-wilson.co.uk>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Matthew Auld <matthew.william.auld@gmail.com>
> Cc: David Herrmann <dh.herrmann@gmail.com>
Shame about the BUG_ON, but probably overkill to add code to suppress
the RO flag just for mmap.
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v2] drm/i915: Prevent writing into a read-only object via a GGTT mmap
2018-06-14 16:36 ` Bloomfield, Jon
@ 2018-06-14 16:48 ` Chris Wilson
0 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 16:48 UTC (permalink / raw)
To: Bloomfield, Jon, intel-gfx; +Cc: dri-devel, David Herrmann
Quoting Bloomfield, Jon (2018-06-14 17:36:29)
> > -----Original Message-----
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> > Sent: Thursday, June 14, 2018 9:07 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson <chris@chris-wilson.co.uk>;
> > Bloomfield, Jon <jon.bloomfield@intel.com>; Joonas Lahtinen
> > <joonas.lahtinen@linux.intel.com>; Matthew Auld
> > <matthew.william.auld@gmail.com>; David Herrmann
> > <dh.herrmann@gmail.com>
> > Subject: [PATCH v2] drm/i915: Prevent writing into a read-only object via a
> > GGTT mmap
> >
> > 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@chris-wilson.co.uk>
> > Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Matthew Auld <matthew.william.auld@gmail.com>
> > Cc: David Herrmann <dh.herrmann@gmail.com>
>
> Shame about the BUG_ON, but probably overkill to add code to suppress
> the RO flag just for mmap.
>
> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Maybe one day with a PIN_RO, we can put it back in again.
Just a feeling of unease for shadowing cache_level on the vma. If only
we could just erase the history of doing cache_domain tracking.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
2018-06-14 11:59 ` [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+ Chris Wilson
2018-06-14 11:59 ` [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap Chris Wilson
@ 2018-06-14 11:59 ` Chris Wilson
2018-06-14 16:54 ` Bloomfield, Jon
2018-06-14 11:59 ` [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+ Chris Wilson
` (2 subsequent siblings)
5 siblings, 1 reply; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 11:59 UTC (permalink / raw)
To: intel-gfx
If the user created a read-only object, they should not be allowed to
circumvent the write protection using the pwrite ioctl.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d5eb73f7a90a..cf02c4702218 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1623,6 +1623,12 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
goto err;
}
+ /* Writes not allowed into this read-only object */
+ if (obj->gt_ro) {
+ ret = -EINVAL;
+ goto err;
+ }
+
trace_i915_gem_object_pwrite(obj, args->offset, args->size);
ret = -ENODEV;
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object
2018-06-14 11:59 ` [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object Chris Wilson
@ 2018-06-14 16:54 ` Bloomfield, Jon
0 siblings, 0 replies; 21+ messages in thread
From: Bloomfield, Jon @ 2018-06-14 16:54 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, June 14, 2018 5:00 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> <jon.bloomfield@intel.com>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>; Matthew Auld
> <matthew.william.auld@gmail.com>
> Subject: [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only
> object
>
> If the user created a read-only object, they should not be allowed to
> circumvent the write protection using the pwrite ioctl.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Matthew Auld <matthew.william.auld@gmail.com>
> ---
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
` (2 preceding siblings ...)
2018-06-14 11:59 ` [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object Chris Wilson
@ 2018-06-14 11:59 ` Chris Wilson
2018-06-14 16:51 ` Bloomfield, Jon
2018-06-14 12:05 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Patchwork
2018-06-14 16:39 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode (rev2) Patchwork
5 siblings, 1 reply; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 11:59 UTC (permalink / raw)
To: intel-gfx
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 854bd51b9478..d4ee8fa4c379 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -789,10 +789,12 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -EFAULT;
if (args->flags & I915_USERPTR_READ_ONLY) {
- /* On almost all of the current hw, we cannot tell the GPU that a
- * page is readonly, so this is just a placeholder in the uAPI.
+ /*
+ * On almost all of the older hw, we cannot tell the GPU that
+ * a page is readonly.
*/
- return -ENODEV;
+ if (INTEL_GEN(dev_priv) < 8 || !USES_PPGTT(dev_priv))
+ return -ENODEV;
}
obj = i915_gem_object_alloc(dev_priv);
@@ -806,7 +808,10 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
obj->userptr.ptr = args->user_ptr;
- obj->userptr.read_only = !!(args->flags & I915_USERPTR_READ_ONLY);
+ if (args->flags & I915_USERPTR_READ_ONLY) {
+ obj->userptr.read_only = true;
+ obj->gt_ro = true;
+ }
/* And keep a pointer to the current->mm for resolving the user pages
* at binding. This means that we need to hook into the mmu_notifier
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+
2018-06-14 11:59 ` [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+ Chris Wilson
@ 2018-06-14 16:51 ` Bloomfield, Jon
0 siblings, 0 replies; 21+ messages in thread
From: Bloomfield, Jon @ 2018-06-14 16:51 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, June 14, 2018 5:00 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson <chris@chris-wilson.co.uk>; Bloomfield, Jon
> <jon.bloomfield@intel.com>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>
> Subject: [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+
>
> On gen8 and onwards, we can mark GPU accesses through the ppGTT as
> being
> read-only, that is cause any GPU write onto that page to be discarded
> (not triggering a fault). This is all that we need to finally support
> the read-only flag for userptr!
>
> Testcase: igt/gem_userptr_blits/readonly*
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
` (3 preceding siblings ...)
2018-06-14 11:59 ` [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+ Chris Wilson
@ 2018-06-14 12:05 ` Patchwork
2018-06-14 16:39 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode (rev2) Patchwork
5 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2018-06-14 12:05 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/44750/
State : failure
== Summary ==
Applying: drm/i915/gtt: Add read only pages to gen8_pte_encode
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_gem_gtt.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/gtt: Add read only pages to gen8_pte_encode
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode (rev2)
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
` (4 preceding siblings ...)
2018-06-14 12:05 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Patchwork
@ 2018-06-14 16:39 ` Patchwork
5 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2018-06-14 16:39 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode (rev2)
URL : https://patchwork.freedesktop.org/series/44750/
State : failure
== Summary ==
Applying: drm/i915/gtt: Add read only pages to gen8_pte_encode
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_gem_gtt.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/gtt: Add read only pages to gen8_pte_encode
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
@ 2018-06-14 19:24 Chris Wilson
0 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2018-06-14 19:24 UTC (permalink / raw)
To: intel-gfx
From: Jon Bloomfield <jon.bloomfield@intel.com>
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8883e75cb594..c3630abbd260 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -244,10 +244,13 @@ static void clear_pages(struct i915_vma *vma)
}
static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
- enum i915_cache_level level)
+ enum i915_cache_level level,
+ u32 flags)
{
- gen8_pte_t pte = _PAGE_PRESENT | _PAGE_RW;
- pte |= addr;
+ gen8_pte_t pte = addr | _PAGE_PRESENT | _PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~_PAGE_RW;
switch (level) {
case I915_CACHE_NONE:
@@ -637,7 +640,7 @@ static void gen8_initialize_pt(struct i915_address_space *vm,
struct i915_page_table *pt)
{
fill_px(vm, pt,
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC));
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0));
}
static void gen6_initialize_pt(struct i915_address_space *vm,
@@ -786,7 +789,7 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space *vm,
unsigned int pte = gen8_pte_index(start);
unsigned int pte_end = pte + num_entries;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t *vaddr;
GEM_BUG_ON(num_entries > pt->used_ptes);
@@ -961,7 +964,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
enum i915_cache_level cache_level)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
gen8_pte_t *vaddr;
bool ret;
@@ -1029,7 +1032,7 @@ static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct sgt_dma *iter,
enum i915_cache_level cache_level)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1495,7 +1498,7 @@ static void gen8_dump_ppgtt(struct i915_hw_ppgtt *ppgtt, struct seq_file *m)
{
struct i915_address_space *vm = &ppgtt->vm;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
u64 start = 0, length = ppgtt->vm.total;
if (use_4lvl(vm)) {
@@ -2397,7 +2400,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
- gen8_set_pte(pte, gen8_pte_encode(addr, level));
+ gen8_set_pte(pte, gen8_pte_encode(addr, level, 0));
ggtt->invalidate(vm->i915);
}
@@ -2410,7 +2413,7 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
gen8_pte_t __iomem *gtt_entries;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
@@ -2478,7 +2481,7 @@ static void gen8_ggtt_clear_range(struct i915_address_space *vm,
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t __iomem *gtt_base =
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
@ 2018-05-31 11:35 Chris Wilson
2018-05-31 14:43 ` Matthew Auld
0 siblings, 1 reply; 21+ messages in thread
From: Chris Wilson @ 2018-05-31 11:35 UTC (permalink / raw)
To: intel-gfx
From: Jon Bloomfield <jon.bloomfield@intel.com>
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f4def556f40..5936f0bfdd19 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -244,10 +244,13 @@ static void clear_pages(struct i915_vma *vma)
}
static gen8_pte_t gen8_pte_encode(dma_addr_t addr,
- enum i915_cache_level level)
+ enum i915_cache_level level,
+ u32 flags)
{
- gen8_pte_t pte = _PAGE_PRESENT | _PAGE_RW;
- pte |= addr;
+ gen8_pte_t pte = addr | _PAGE_PRESENT | _PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~_PAGE_RW;
switch (level) {
case I915_CACHE_NONE:
@@ -637,7 +640,7 @@ static void gen8_initialize_pt(struct i915_address_space *vm,
struct i915_page_table *pt)
{
fill_px(vm, pt,
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC));
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0));
}
static void gen6_initialize_pt(struct i915_address_space *vm,
@@ -833,7 +836,7 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space *vm,
unsigned int pte = gen8_pte_index(start);
unsigned int pte_end = pte + num_entries;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t *vaddr;
GEM_BUG_ON(num_entries > pt->used_ptes);
@@ -1008,7 +1011,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
enum i915_cache_level cache_level)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
gen8_pte_t *vaddr;
bool ret;
@@ -1076,7 +1079,7 @@ static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct sgt_dma *iter,
enum i915_cache_level cache_level)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1542,7 +1545,7 @@ static void gen8_dump_ppgtt(struct i915_hw_ppgtt *ppgtt, struct seq_file *m)
{
struct i915_address_space *vm = &ppgtt->base;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
u64 start = 0, length = ppgtt->base.total;
if (use_4lvl(vm)) {
@@ -2419,7 +2422,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
- gen8_set_pte(pte, gen8_pte_encode(addr, level));
+ gen8_set_pte(pte, gen8_pte_encode(addr, level, 0));
ggtt->invalidate(vm->i915);
}
@@ -2432,7 +2435,7 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
gen8_pte_t __iomem *gtt_entries;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, level);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
@@ -2500,7 +2503,7 @@ static void gen8_ggtt_clear_range(struct i915_address_space *vm,
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
const gen8_pte_t scratch_pte =
- gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC);
+ gen8_pte_encode(vm->scratch_page.daddr, I915_CACHE_LLC, 0);
gen8_pte_t __iomem *gtt_base =
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
2018-05-31 11:35 Chris Wilson
@ 2018-05-31 14:43 ` Matthew Auld
2018-05-31 15:00 ` Chris Wilson
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Auld @ 2018-05-31 14:43 UTC (permalink / raw)
To: Chris Wilson; +Cc: Intel Graphics Development
On 31 May 2018 at 12:35, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> From: Jon Bloomfield <jon.bloomfield@intel.com>
>
> We can set a bit inside the ppGTT PTE to indicate a page is read-only;
> writes from the GPU will be discarded. We can use this to protect pages
> and in particular support read-only userptr mappings (necessary for
> importing PROT_READ vma).
>
> Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Matthew Auld <matthew.william.auld@gmail.com>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
fwiw I didn't see any surprises with ro 2M/64K PTEs when testing locally.
For the series:
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode
2018-05-31 14:43 ` Matthew Auld
@ 2018-05-31 15:00 ` Chris Wilson
0 siblings, 0 replies; 21+ messages in thread
From: Chris Wilson @ 2018-05-31 15:00 UTC (permalink / raw)
To: Matthew Auld; +Cc: Intel Graphics Development
Quoting Matthew Auld (2018-05-31 15:43:14)
> On 31 May 2018 at 12:35, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > From: Jon Bloomfield <jon.bloomfield@intel.com>
> >
> > We can set a bit inside the ppGTT PTE to indicate a page is read-only;
> > writes from the GPU will be discarded. We can use this to protect pages
> > and in particular support read-only userptr mappings (necessary for
> > importing PROT_READ vma).
> >
> > Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Matthew Auld <matthew.william.auld@gmail.com>
> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>
> fwiw I didn't see any surprises with ro 2M/64K PTEs when testing locally.
>
> For the series:
> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
I think I'd like to see a selftest also exercising the ro nature before
pushing. Thanks for the review, stick around there'll be another patch
to come :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2018-06-14 19:24 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-14 11:59 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
2018-06-14 11:59 ` [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+ Chris Wilson
2018-06-14 11:59 ` [PATCH 3/5] drm/i915: Prevent writing into a read-only object via a GGTT mmap Chris Wilson
2018-06-14 14:53 ` Bloomfield, Jon
2018-06-14 15:00 ` Chris Wilson
2018-06-14 15:06 ` Bloomfield, Jon
2018-06-14 15:21 ` Chris Wilson
2018-06-14 15:33 ` Bloomfield, Jon
2018-06-14 16:06 ` [PATCH v2] " Chris Wilson
2018-06-14 16:36 ` Bloomfield, Jon
2018-06-14 16:48 ` Chris Wilson
2018-06-14 11:59 ` [PATCH 4/5] drm/i915: Reject attempted pwrites into a read-only object Chris Wilson
2018-06-14 16:54 ` Bloomfield, Jon
2018-06-14 11:59 ` [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+ Chris Wilson
2018-06-14 16:51 ` Bloomfield, Jon
2018-06-14 12:05 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Patchwork
2018-06-14 16:39 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode (rev2) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2018-06-14 19:24 [PATCH 1/5] drm/i915/gtt: Add read only pages to gen8_pte_encode Chris Wilson
2018-05-31 11:35 Chris Wilson
2018-05-31 14:43 ` Matthew Auld
2018-05-31 15:00 ` Chris Wilson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.