We were hardcoding the SnJ and So IDs already at the trans_cfg
selection, instead of doing it in a more generic way. Use the generic
trans_cfg selection for these devices and move the hardcoded IDs to
the new table.
type=feature
ticket=none
Change-Id: I6f65126175d54b73834c2896013d00ce114ff601
Signed-off-by: Luca Coelho <email address hidden>
Reviewed-on: https://git-amr-3.devtools.intel.com/gerrit/279040
automatic-review: ec ger unix iil jenkins <email address hidden>
Reviewed-by: Johannes Berg <email address hidden>
Tested-by: ec ger unix iil jenkins <email address hidden>
(backported from commit 0001-iwlwifi-move-SnJ-and-So-rules-to-the-new-tables.patch)
Signed-off-by: You-Sheng Yang <email address hidden>
Currently we leave the cache_level of the initial fb obj
set to NONE. This means on eLLC machines the first pin_to_display()
will try to switch it to WT which requires a vma unbind+bind.
If that happens during the fbdev initialization rcu does not
seem operational which causes the unbind to get stuck. To
most appearances this looks like a dead machine on boot.
Avoid the unbind by already marking the object cache_level
as WT when creating it. We still do an excplicit ggtt pin
which will rewrite the PTEs anyway, so they will match whatever
cache level we set.
Cc: <email address hidden> # v5.7+
Suggested-by: Chris Wilson <email address hidden>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
Signed-off-by: Ville Syrjälä <email address hidden>
Reviewed-by: Chris Wilson <email address hidden>
Signed-off-by: Chris Wilson <email address hidden>
Link: https://patchwork.<email address hidden>
Link: https://patchwork<email address hidden>
(cherry picked from commit d46b60a2e8d246f1f0faa38e52f4f5a73858c338)
Signed-off-by: Rodrigo Vivi <email address hidden>
(cherry picked from commit 1664ffee760a5d98952318fdd9b198fae396d660)
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Kelsey Skunberg <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Add a test modelled on the RFI flush test which counts the number
of L1D misses doing a simple syscall with the entry flush on and off.
For simplicity of backporting, this test duplicates a lot of code from
rfi_flush. We clean that up in the next patch.
Signed-off-by: Daniel Axtens <email address hidden>
CVE-2020-4788
(backported from commit 89a83a0c69c81a25ce91002b90ca27ed86132a0a)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Juerg Haefliger <email address hidden>
9e09d17...
by
Nicholas Piggin <email address hidden>
powerpc/64s: flush L1D after user accesses
IBM Power9 processors can speculatively operate on data in the L1 cache before
it has been completely validated, via a way-prediction mechanism. It is not possible
for an attacker to determine the contents of impermissible memory using this method,
since these systems implement a combination of hardware and software security measures
to prevent scenarios where protected data could be leaked.
However these measures don't address the scenario where an attacker induces
the operating system to speculatively execute instructions using data that the
attacker controls. This can be used for example to speculatively bypass "kernel
user access prevention" techniques, as discovered by Anthony Steinhauser of
Google's Safeside Project. This is not an attack by itself, but there is a possibility
it could be used in conjunction with side-channels or other weaknesses in the
privileged code to construct an attack.
This issue can be mitigated by flushing the L1 cache between privilege boundaries
of concern. This patch flushes the L1 cache after user accesses.
This is part of the fix for CVE-2020-4788.
Signed-off-by: Nicholas Piggin <email address hidden>
Signed-off-by: Daniel Axtens <email address hidden>
CVE-2020-4788
(backported from commit 9a32a7e78bd0cd9a9b6332cbdc345ee5ffd0c5de)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Juerg Haefliger <email address hidden>
752dfc5...
by
Nicholas Piggin <email address hidden>
powerpc/64s: flush L1D on kernel entry
IBM Power9 processors can speculatively operate on data in the L1 cache before
it has been completely validated, via a way-prediction mechanism. It is not possible
for an attacker to determine the contents of impermissible memory using this method,
since these systems implement a combination of hardware and software security measures
to prevent scenarios where protected data could be leaked.
However these measures don't address the scenario where an attacker induces
the operating system to speculatively execute instructions using data that the
attacker controls. This can be used for example to speculatively bypass "kernel
user access prevention" techniques, as discovered by Anthony Steinhauser of
Google's Safeside Project. This is not an attack by itself, but there is a possibility
it could be used in conjunction with side-channels or other weaknesses in the
privileged code to construct an attack.
This issue can be mitigated by flushing the L1 cache between privilege boundaries
of concern. This patch flushes the L1 cache on kernel entry.
This is part of the fix for CVE-2020-4788.
Signed-off-by: Nicholas Piggin <email address hidden>
Signed-off-by: Daniel Axtens <email address hidden>
CVE-2020-4788
(backported from commit f79643787e0a0762d2409b7b8334e83f22d85695)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Juerg Haefliger <email address hidden>
c5e2da8...
by
Russell Currey <email address hidden>
selftests/powerpc: rfi_flush: disable entry flush if present
We are about to add an entry flush. The rfi (exit) flush test measures
the number of L1D flushes over a syscall with the RFI flush enabled and
disabled. But if the entry flush is also enabled, the effect of enabling
and disabling the RFI flush is masked.
If there is a debugfs entry for the entry flush, disable it during the RFI
flush and restore it later.
Reported-by: Spoorthy S <email address hidden>
Signed-off-by: Russell Currey <email address hidden>
Signed-off-by: Daniel Axtens <email address hidden>
CVE-2020-4788
(backported from commit fcb48454c23c5679d1a2e252f127642e91b05cbe)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Juerg Haefliger <email address hidden>
