Module Name: src
Committed By: martin
Date: Thu Dec 12 21:00:32 UTC 2019
Modified Files:
src/sys/external/bsd/common/include/linux [netbsd-9]: bitops.h
src/sys/external/bsd/drm2/dist/drm/i915 [netbsd-9]: i915_cmd_parser.c
i915_dma.c i915_drv.c i915_drv.h i915_gem_context.c
i915_gem_execbuffer.c i915_gem_gtt.c i915_gem_gtt.h i915_reg.h
intel_display.c intel_drv.h intel_pm.c intel_ringbuffer.c
intel_ringbuffer.h
Log Message:
Pull up following revision(s) (requested by maya in ticket #548):
sys/external/bsd/drm2/dist/drm/i915/intel_display.c: revision 1.28
sys/external/bsd/drm2/dist/drm/i915/i915_drv.h: revision 1.30
sys/external/bsd/common/include/linux/bitops.h: revision 1.9
sys/external/bsd/drm2/dist/drm/i915/intel_drv.h: revision 1.11
sys/external/bsd/drm2/dist/drm/i915/i915_gem_gtt.h: revision 1.8
sys/external/bsd/drm2/dist/drm/i915/i915_gem_gtt.c: revision 1.16
sys/external/bsd/drm2/dist/drm/i915/i915_gem_execbuffer.c: revision 1.9
sys/external/bsd/drm2/dist/drm/i915/i915_dma.c: revision 1.28
sys/external/bsd/drm2/dist/drm/i915/i915_cmd_parser.c: revision 1.19
sys/external/bsd/drm2/dist/drm/i915/intel_pm.c: revision 1.20
sys/external/bsd/drm2/dist/drm/i915/intel_ringbuffer.c: revision 1.11
sys/external/bsd/drm2/dist/drm/i915/intel_ringbuffer.h: revision 1.7
sys/external/bsd/drm2/dist/drm/i915/i915_reg.h: revision 1.14
sys/external/bsd/drm2/dist/drm/i915/i915_cmd_parser.c: revision 1.20
sys/external/bsd/drm2/dist/drm/i915/i915_gem_context.c: revision 1.10
sys/external/bsd/drm2/dist/drm/i915/i915_drv.c: revision 1.17
Add what appears to be the fixes to CVE-2019-0154, CVE-2019-0155.
This commit requires review, but I'd also like it to be tested by others
while it is being reviewed.
CVE-2019-0155:
It was discovered that the Intel i915 graphics chipsets allowed userspace
to modify page table entries via writes to MMIO from the Blitter Command
Streamer and expose kernel memory information. A local attacker could use
this to expose sensitive information or possibly elevate privileges.
CVE-2019-0154:
It was discovered that the Intel i915 graphics chipsets could cause
a system hang when userspace performed a read from GT memory mapped
input output (MMIO) when the product is in certain low power states.
A local attacker could use this to cause a denial of service.
>From upstream commits to linux-4.4.y:
-------------------
>From 6d0cfddc7afc715835f0e17827106f832b14dd2a Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Thu, 12 Jul 2018 19:53:10 +0100
Subject: [PATCH] drm/i915/gtt: Add read only pages to gen8_pte_encode
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).
-------------------
>From 774b68aa2105c70b40c3b1777feb7ab500d716dd Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Mon, 6 Aug 2018 14:10:48 -0700
Subject: [PATCH] drm/i915/gtt: Read-only pages for insert_entries on bdw+
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
v3: Don't duplicate cpu_check() as we can just reuse it, and even worse
don't wholesale copy the theory-of-operation comment from igt_ctx_exec
without changing it to explain the intention behind the new test!
v4: Joonas really likes magic mystery values
-------------------
>From 3fd1c2e65c60c1c513155e1d1d74138b141aa8a3 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris%chris-wilson.co.uk@localhost>
Date: Thu, 12 Jul 2018 19:53:12 +0100
Subject: [PATCH] drm/i915/gtt: Disable read-only support under GVT
GVT is not propagating the PTE bits, and is always setting the
read-write bit, thus breaking read-only support.
-------------------
>From e5e3c0154c19f2d8213e0af88b7a10d9de7fbafd Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Fri, 20 Apr 2018 14:26:01 -0700
Subject: [PATCH] drm/i915: Rename gen7 cmdparser tables
We're about to introduce some new tables for later gens, and the
current naming for the gen7 tables will no longer make sense.
v2: rebase
-------------------
>From 3122671a5df3ee13f5cf22b7bdacf422b7b4319a Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Fri, 8 Jun 2018 08:53:46 -0700
Subject: [PATCH] drm/i915: Disable Secure Batches for gen6+
Retroactively stop reporting support for secure batches
through the api for gen6+ so that older binaries trigger
the fallback path instead.
Older binaries use secure batches pre gen6 to access resources
that are not available to normal usermode processes. However,
all known userspace explicitly checks for HAS_SECURE_BATCHES
before relying on the secure batch feature.
Since there are no known binaries relying on this for newer gens
we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES.
v2: rebase (Mika)
v3: rebase (Mika)
-------------------
>From 544fd7d9d4cfe32357beab2f1dc543637d42e69f Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Fri, 8 Jun 2018 10:05:26 -0700
Subject: [PATCH] drm/i915: Remove Master tables from cmdparser
The previous patch has killed support for secure batches
on gen6+, and hence the cmdparsers master tables are
now dead code. Remove them.
-------------------
>From 17e89f38212d8b3cba470efca91b997ac03c592c Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Wed, 1 Aug 2018 09:33:59 -0700
Subject: [PATCH] drm/i915: Add support for mandatory cmdparsing
The existing cmdparser for gen7 can be bypassed by specifying
batch_len=0 in the execbuf call. This is safe because bypassing
simply reduces the cmd-set available.
In a later patch we will introduce cmdparsing for gen9, as a
security measure, which must be strictly enforced since without
it we are vulnerable to DoS attacks.
Introduce the concept of 'required' cmd parsing that cannot be
bypassed by submitting zero-length bb's.
v2: rebase (Mika)
v2: rebase (Mika)
v3: fix conflict on engine flags (Mika)
-------------------
>From 77524398bccea3592a25cbe92a9a54fa555013af Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Tue, 22 May 2018 13:59:06 -0700
Subject: [PATCH] drm/i915: Support ro ppgtt mapped cmdparser shadow buffers
For Gen7, the original cmdparser motive was to permit limited
use of register read/write instructions in unprivileged BB's.
This worked by copying the user supplied bb to a kmd owned
bb, and running it in secure mode, from the ggtt, only if
the scanner finds no unsafe commands or registers.
For Gen8+ we can't use this same technique because running bb's
from the ggtt also disables access to ppgtt space. But we also
do not actually require 'secure' execution since we are only
trying to reduce the available command/register set. Instead we
will copy the user buffer to a kmd owned read-only bb in ppgtt,
and run in the usual non-secure mode.
Note that ro pages are only supported by ppgtt (not ggtt), but
luckily that's exactly what we need.
Add the required paths to map the shadow buffer to ppgtt ro for Gen8+
v2: IS_GEN7/IS_GEN (Mika)
v3: rebase
v4: rebase
v5: rebase
-------------------
>From 2ac501479a1325d00aca5012887ebfece8358032 Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Wed, 1 Aug 2018 09:45:50 -0700
Subject: [PATCH] drm/i915: Allow parsing of unsized batches
In "drm/i915: Add support for mandatory cmdparsing" we introduced the
concept of mandatory parsing. This allows the cmdparser to be invoked
even when user passes batch_len=0 to the execbuf ioctl's.
However, the cmdparser needs to know the extents of the buffer being
scanned. Refactor the code to ensure the cmdparser uses the actual
object size, instead of the incoming length, if user passes 0.
-------------------
>From 57c2c8f58ca07e8045f020e4e2548ac3bc3a5aab Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Mon, 23 Apr 2018 11:12:15 -0700
Subject: [PATCH] drm/i915: Add gen9 BCS cmdparsing
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)
-------------------
>From d88d2d3fc6076760e903e78135f5bef028e6e813 Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Fri, 21 Sep 2018 13:18:09 -0700
Subject: [PATCH] drm/i915/cmdparser: Add support for backward jumps
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)
-------------------
>From 362917ebcfacbd9c2b5172d5a5fe8cbef3ab838f Mon Sep 17 00:00:00 2001
From: Jon Bloomfield <jon.bloomfield%intel.com@localhost>
Date: Thu, 20 Sep 2018 09:45:10 -0700
Subject: [PATCH] drm/i915/cmdparser: Ignore Length operands during command
matching
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
-------------------
>From 1433b8d41b1aa346e100b839c19fc033871ac5a6 Mon Sep 17 00:00:00 2001
From: Uma Shankar <uma.shankar%intel.com@localhost>
Date: Tue, 7 Aug 2018 21:15:35 +0530
Subject: [PATCH] drm/i915: Lower RM timeout to avoid DSI hard hangs
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.
-------------------
>From 284d38667f7ed7171fd8f168c42490f9087c824c Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak%intel.com@localhost>
Date: Mon, 9 Jul 2018 18:24:27 +0300
Subject: [PATCH] drm/i915/gen8+: Add RC6 CTX corruption WA
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->uncore, ...) API
change.
v5: rebased on gem/gt split (Mika)
-------------------
>From 6dd52bae8a01af77236b88917e84e84dbcfe06db Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben%decadent.org.uk@localhost>
Date: Mon, 11 Nov 2019 08:13:24 -0800
Subject: [PATCH] drm/i915/cmdparser: Fix jump whitelist clearing
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.
Use the original linux function rather than my wrong translation.
-
...Include the header to have it.
Thanks Riastradh!
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.8.8.1 \
src/sys/external/bsd/common/include/linux/bitops.h
cvs rdiff -u -r1.18 -r1.18.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_cmd_parser.c
cvs rdiff -u -r1.27 -r1.27.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_dma.c
cvs rdiff -u -r1.16 -r1.16.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_drv.c
cvs rdiff -u -r1.29 -r1.29.2.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_drv.h
cvs rdiff -u -r1.9 -r1.9.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_gem_context.c \
src/sys/external/bsd/drm2/dist/drm/i915/intel_ringbuffer.c
cvs rdiff -u -r1.8 -r1.8.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_gem_execbuffer.c
cvs rdiff -u -r1.15 -r1.15.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_gem_gtt.c
cvs rdiff -u -r1.7 -r1.7.8.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_gem_gtt.h
cvs rdiff -u -r1.7 -r1.7.2.1 \
src/sys/external/bsd/drm2/dist/drm/i915/i915_reg.h
cvs rdiff -u -r1.26 -r1.26.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/intel_display.c
cvs rdiff -u -r1.10 -r1.10.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/intel_drv.h
cvs rdiff -u -r1.17 -r1.17.2.1 \
src/sys/external/bsd/drm2/dist/drm/i915/intel_pm.c
cvs rdiff -u -r1.6 -r1.6.4.1 \
src/sys/external/bsd/drm2/dist/drm/i915/intel_ringbuffer.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
