On 24/07/2020 13:23, Chris Wilson wrote:
Quoting Chris Wilson (2020-07-24 11:19:05)
Quoting Lionel Landwerlin (2020-07-24 11:07:18)
On 24/07/2020 12:26, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2020-07-24 01:18:59)
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index febc9e6692ba..3b1d3dbcd477 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -934,6 +934,10 @@ static bool pardon_reg(struct drm_i915_private *i915, i915_reg_t reg)
static const struct regmask pardon[] = {
{ GEN9_CTX_PREEMPT_REG, INTEL_GEN_MASK(9, 9) },
{ GEN8_L3SQCREG4, INTEL_GEN_MASK(9, 9) },
+ { OAREPORTTRIG2, INTEL_GEN_MASK(8, 11) },
+ { OAREPORTTRIG6, INTEL_GEN_MASK(8, 11) },
+ { GEN12_OAG_OAREPORTTRIG2, INTEL_GEN_MASK(12, 12) },
+ { GEN12_OAG_OAREPORTTRIG6, INTEL_GEN_MASK(12, 12) },
Because we are not making the mistake of exposing more globals, and the
pardon is a list of our past sins, not an excuse for more.
I'm afraid the HW design leave us no choice on Gen12 :(
The question then is how much mischief can a client get up to if they
subvert the OA of the privileged user. It's a privilege escalation hole,
but is there anything dangerous behind it? Or is it just going to disturb
the data being fed to the privileged client... (Which seems scary enough.)
The other angle is whether the RING_NONPRIV are context saved; I have
vague memories of seeing them in the context image. If they are, we can
add them the to privileged OA client. We still need to respect the
hard limit on the number, but that would close the hole.
-Chris
I couldn't find how to do this whitelisting per context. If that's
possible, that's probably what we should do.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
