<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/i915, branch v4.9.289</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.289</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.289'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-01-17T12:57:54+00:00</updated>
<entry>
<title>drm/i915: Fix mismatch between misplaced vma check and vma insert</title>
<updated>2021-01-17T12:57:54+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2020-12-16T09:29:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=765c00a17a141756156d2d855257f6ca5a883af2'/>
<id>urn:sha1:765c00a17a141756156d2d855257f6ca5a883af2</id>
<content type='text'>
commit 0e53656ad8abc99e0a80c3de611e593ebbf55829 upstream

When inserting a VMA, we restrict the placement to the low 4G unless the
caller opts into using the full range. This was done to allow usersapce
the opportunity to transition slowly from a 32b address space, and to
avoid breaking inherent 32b assumptions of some commands.

However, for insert we limited ourselves to 4G-4K, but on verification
we allowed the full 4G. This causes some attempts to bind a new buffer
to sporadically fail with -ENOSPC, but at other times be bound
successfully.

commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
page") suggests that there is a genuine problem with stateless addressing
that cannot utilize the last page in 4G and so we purposefully excluded
it. This means that the quick pin pass may cause us to utilize a buggy
placement.

Reported-by: CQ Tang &lt;cq.tang@intel.com&gt;
Testcase: igt/gem_exec_params/larger-than-life-batch
Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: CQ Tang &lt;cq.tang@intel.com&gt;
Reviewed-by: CQ Tang &lt;cq.tang@intel.com&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.5+
Link: https://patchwork.freedesktop.org/patch/msgid/20201216092951.7124-1-chris@chris-wilson.co.uk
(cherry picked from commit 5f22cc0b134ab702d7f64b714e26018f7288ffee)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
[sudip: use file from old path and adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Whitelist context-local timestamp in the gen9 cmdparser</title>
<updated>2020-06-30T19:38:32+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2020-06-01T16:19:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5dfd73f2562bfd5ed2998958a3419c4920ebc120'/>
<id>urn:sha1:5dfd73f2562bfd5ed2998958a3419c4920ebc120</id>
<content type='text'>
commit 273500ae71711c040d258a7b3f4b6f44c368fff2 upstream.

Allow batch buffers to read their own _local_ cumulative HW runtime of
their logical context.

Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.4+
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk
(cherry picked from commit f9496520df11de00fbafc3cbd693b9570d600ab3)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/gen9: Clear residual context state on context switch</title>
<updated>2020-01-14T19:04:32+00:00</updated>
<author>
<name>Akeem G Abodunrin</name>
<email>akeem.g.abodunrin@intel.com</email>
</author>
<published>2020-01-08T20:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=571233331e1910206ec365ac61e5b51e77cce3b9'/>
<id>urn:sha1:571233331e1910206ec365ac61e5b51e77cce3b9</id>
<content type='text'>
commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Intel GPU Hardware prior to Gen11 does not clear EU state
during a context switch. This can result in information
leakage between contexts.

For Gen8 and Gen9, hardware provides a mechanism for
fast cleardown of the EU state, by issuing a PIPE_CONTROL
with bit 27 set. We can use this in a context batch buffer
to explicitly cleardown the state on every context switch.

As this workaround is already in place for gen8, we can borrow
the code verbatim for Gen9.

Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Akeem G Abodunrin &lt;akeem.g.abodunrin@intel.com&gt;
Cc: Kumar Valsan Prathap &lt;prathap.kumar.valsan@intel.com&gt;
Cc: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Cc: Balestrieri Francesco &lt;francesco.balestrieri@intel.com&gt;
Cc: Bloomfield Jon &lt;jon.bloomfield@intel.com&gt;
Cc: Dutt Sudeep &lt;sudeep.dutt@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/cmdparser: Fix jump whitelist clearing</title>
<updated>2019-11-12T18:16:24+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2019-11-11T16:13:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=139bb57b355ed8bef2dc619ea9e63923c245557a'/>
<id>urn:sha1:139bb57b355ed8bef2dc619ea9e63923c245557a</id>
<content type='text'>
commit ea0b163b13ffc52818c079adb00d55e227a6da6f upstream.

When a jump_whitelist bitmap is reused, it needs to be cleared.
Currently this is done with memset() and the size calculation assumes
bitmaps are made of 32-bit words, not longs.  So on 64-bit
architectures, only the first half of the bitmap is cleared.

If some whitelist bits are carried over between successive batches
submitted on the same context, this will presumably allow embedding
the rogue instructions that we're trying to reject.

Use bitmap_zero() instead, which gets the calculation right.

Fixes: f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps")
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/gen8+: Add RC6 CTX corruption WA</title>
<updated>2019-11-12T18:16:24+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2018-07-09T15:24:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=00194ecfb32cab5bc20ce1308c681c47094015bd'/>
<id>urn:sha1:00194ecfb32cab5bc20ce1308c681c47094015bd</id>
<content type='text'>
commit 7e34f4e4aad3fd34c02b294a3cf2321adf5b4438 upstream.

In some circumstances the RC6 context can get corrupted. We can detect
this and take the required action, that is disable RC6 and runtime PM.
The HW recovers from the corrupted state after a system suspend/resume
cycle, so detect the recovery and re-enable RC6 and runtime PM.

v2: rebase (Mika)
v3:
- Move intel_suspend_gt_powersave() to the end of the GEM suspend
  sequence.
- Add commit message.
v4:
- Rebased on intel_uncore_forcewake_put(i915-&gt;uncore, ...) API
  change.
v5:
- Rebased on latest upstream gt_pm refactoring.

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Lower RM timeout to avoid DSI hard hangs</title>
<updated>2019-11-12T18:16:23+00:00</updated>
<author>
<name>Uma Shankar</name>
<email>uma.shankar@intel.com</email>
</author>
<published>2018-08-07T15:45:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ebd6ded190ed0920c16eb63f274b50ca050e46fb'/>
<id>urn:sha1:ebd6ded190ed0920c16eb63f274b50ca050e46fb</id>
<content type='text'>
commit 1d85a299c4db57c55e0229615132c964d17aa765 upstream.

In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL
to be turned ON. When MIPI PLL is turned off (MIPI Display is not
active or connected), and someone (host or GT engine) tries to read
MIPI registers, it causes hard hang. This is a hardware restriction
or limitation.

Driver by itself doesn't read MIPI registers when MIPI display is off.
But any userspace application can submit unprivileged batch buffer for
execution. In that batch buffer there can be mmio reads. And these
reads are allowed even for unprivileged applications. If these
register reads are for MIPI DSI controller and MIPI display is not
active during that time, then the MMIO read operation causes system
hard hang and only way to recover is hard reboot. A genuine
process/application won't submit batch buffer like this and doesn't
cause any issue. But on a compromised system, a malign userspace
process/app can generate such batch buffer and can trigger system
hard hang (denial of service attack).

The fix is to lower the internal MMIO timeout value to an optimum
value of 950us as recommended by hardware team. If the timeout is
beyond 1ms (which will hit for any value we choose if MMIO READ on a
DSI specific register is performed without PLL ON), it causes the
system hang. But if the timeout value is lower than it will be below
the threshold (even if timeout happens) and system will not get into
a hung state. This will avoid a system hang without losing any
programming or GT interrupts, taking the worst case of lowest CDCLK
frequency and early DC5 abort into account.

Signed-off-by: Uma Shankar &lt;uma.shankar@intel.com&gt;
Reviewed-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/cmdparser: Ignore Length operands during command matching</title>
<updated>2019-11-12T18:16:23+00:00</updated>
<author>
<name>Jon Bloomfield</name>
<email>jon.bloomfield@intel.com</email>
</author>
<published>2018-09-20T16:45:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd671d06b6232107943ec93cf587aa00ece495af'/>
<id>urn:sha1:bd671d06b6232107943ec93cf587aa00ece495af</id>
<content type='text'>
commit 926abff21a8f29ef159a3ac893b05c6e50e043c3 upstream.

Some of the gen instruction macros (e.g. MI_DISPLAY_FLIP) have the
length directly encoded in them. Since these are used directly in
the tables, the Length becomes part of the comparison used for
matching during parsing. Thus, if the cmd being parsed has a
different length to that in the table, it is not matched and the
cmd is accepted via the default variable length path.

Fix by masking out everything except the Opcode in the cmd tables

Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/cmdparser: Add support for backward jumps</title>
<updated>2019-11-12T18:16:23+00:00</updated>
<author>
<name>Jon Bloomfield</name>
<email>jon.bloomfield@intel.com</email>
</author>
<published>2018-09-20T16:58:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7a1a3e368b5f42e75e14da66c6c9f9825d3217c'/>
<id>urn:sha1:a7a1a3e368b5f42e75e14da66c6c9f9825d3217c</id>
<content type='text'>
commit f8c08d8faee5567803c8c533865296ca30286bbf upstream.

To keep things manageable, the pre-gen9 cmdparser does not
attempt to track any form of nested BB_START's. This did not
prevent usermode from using nested starts, or even chained
batches because the cmdparser is not strictly enforced pre gen9.

Instead, the existence of a nested BB_START would cause the batch
to be emitted in insecure mode, and any privileged capabilities
would not be available.

For Gen9, the cmdparser becomes mandatory (for BCS at least), and
so not providing any form of nested BB_START support becomes
overly restrictive. Any such batch will simply not run.

We make heavy use of backward jumps in igt, and it is much easier
to add support for this restricted subset of nested jumps, than to
rewrite the whole of our test suite to avoid them.

Add the required logic to support limited backward jumps, to
instructions that have already been validated by the parser.

Note that it's not sufficient to simply approve any BB_START
that jumps backwards in the buffer because this would allow an
attacker to embed a rogue instruction sequence within the
operand words of a harmless instruction (say LRI) and jump to
that.

We introduce a bit array to track every instr offset successfully
validated, and test the target of BB_START against this. If the
target offset hits, it is re-written to the same offset in the
shadow buffer and the BB_START cmd is allowed.

Note: This patch deliberately ignores checkpatch issues in the
cmdtables, in order to match the style of the surrounding code.
We'll correct the entire file in one go in a later patch.

v2: set dispatch secure late (Mika)
v3: rebase (Mika)
v4: Clear whitelist on each parse
Minor review updates (Chris)
v5: Correct backward jump batching
v6: fix compilation error due to struct eb shuffle (Mika)

Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/cmdparser: Use explicit goto for error paths</title>
<updated>2019-11-12T18:16:22+00:00</updated>
<author>
<name>Jon Bloomfield</name>
<email>jon.bloomfield@intel.com</email>
</author>
<published>2018-09-27T17:23:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=81848cc9c57295e05c8ba81fa2b2b4b8a3962c3c'/>
<id>urn:sha1:81848cc9c57295e05c8ba81fa2b2b4b8a3962c3c</id>
<content type='text'>
commit 0546a29cd884fb8184731c79ab008927ca8859d0 upstream.

In the next patch we will be adding a second valid
termination condition which will require a small
amount of refactoring to share logic with the BB_END
case.

Refactor all error conditions to jump to a dedicated
exit path, with 'break' reserved only for a successful
parse.

Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Add gen9 BCS cmdparsing</title>
<updated>2019-11-12T18:16:22+00:00</updated>
<author>
<name>Jon Bloomfield</name>
<email>jon.bloomfield@intel.com</email>
</author>
<published>2018-04-23T18:12:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6ba2df10d64d6d113ac3e033e3c4b80a3febd66'/>
<id>urn:sha1:a6ba2df10d64d6d113ac3e033e3c4b80a3febd66</id>
<content type='text'>
commit 0f2f39758341df70202ae1c42d5a1e4ee392b6d3 upstream.

For gen9 we enable cmdparsing on the BCS ring, specifically
to catch inadvertent accesses to sensitive registers

Unlike gen7/hsw, we use the parser only to block certain
registers. We can rely on h/w to block restricted commands,
so the command tables only provide enough info to allow the
parser to delineate each command, and identify commands that
access registers.

Note: This patch deliberately ignores checkpatch issues in
favour of matching the style of the surrounding code. We'll
correct the entire file in one go in a later patch.

v3: rebase (Mika)
v4: Add RING_TIMESTAMP registers to whitelist (Jon)

Signed-off-by: Jon Bloomfield &lt;jon.bloomfield@intel.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
