Commit 939204e4 authored by Jason Gunthorpe's avatar Jason Gunthorpe
Browse files

Merge tag 'v6.2' into iommufd.git for-next 



Resolve conflicts from the signature change in iommu_map:

 - drivers/infiniband/hw/usnic/usnic_uiom.c
   Switch iommu_map_atomic() to iommu_map(.., GFP_ATOMIC)

 - drivers/vfio/vfio_iommu_type1.c
   Following indenting change for GFP_KERNEL

Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
parents b4ff830e c9c3395d

.mailmap

+6 −0
Original line number Diff line number Diff line
@@ -25,6 +25,8 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com> 
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>

Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>

Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>

Alexander Mikhalitsyn <alexander@mihalicyn.com> <alexander.mikhalitsyn@virtuozzo.com>

Alexander Mikhalitsyn <alexander@mihalicyn.com> <aleksandr.mikhalitsyn@canonical.com>

Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>

Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>

Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
@@ -130,6 +132,7 @@ Domen Puncer <domen@coderock.org> 
Douglas Gilbert <dougg@torque.net>

Ed L. Cashin <ecashin@coraid.com>

Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>

Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>

Evgeniy Polyakov <johnpol@2ka.mipt.ru>

Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>

Felipe W Damasio <felipewd@terra.com.br>
@@ -214,6 +217,7 @@ Jisheng Zhang <jszhang@kernel.org> <jszhang@marvell.com> 
Jisheng Zhang <jszhang@kernel.org> <Jisheng.Zhang@synaptics.com>

Johan Hovold <johan@kernel.org> <jhovold@gmail.com>

Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>

John Crispin <john@phrozen.org> <blogic@openwrt.org>

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

John Stultz <johnstul@us.ibm.com>

Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
@@ -371,6 +375,7 @@ Rémi Denis-Courmont <rdenis@simphalempin.com> 
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>

Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>

Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>

Robert Foss <rfoss@kernel.org> <robert.foss@linaro.org>

Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>

Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>

Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
@@ -422,6 +427,7 @@ Tony Luck <tony.luck@intel.com> 
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>

TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>

Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>

Tudor Ambarus <tudor.ambarus@linaro.org> <tudor.ambarus@microchip.com>

Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>

Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>

Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>

CREDITS

+15 −0
Original line number Diff line number Diff line
@@ -1173,6 +1173,10 @@ D: Future Domain TMC-16x0 SCSI driver (author) 
D: APM driver (early port)

D: DRM drivers (author of several)



N: Veaceslav Falico

E: vfalico@gmail.com

D: Co-maintainer and co-author of the network bonding driver.



N: János Farkas

E: chexum@shadow.banki.hu

D: romfs, various (mostly networking) fixes
@@ -2489,6 +2493,13 @@ D: XF86_Mach8 
D: XF86_8514

D: cfdisk (curses based disk partitioning program)



N: Mat Martineau

E: mat@martineau.name

D: MPTCP subsystem co-maintainer 2020-2023

D: Keyctl restricted keyring and Diffie-Hellman UAPI

D: Bluetooth L2CAP ERTM mode and AMP

S: USA



N: John S. Marvin

E: jsm@fc.hp.com

D: PA-RISC port
@@ -4172,6 +4183,10 @@ S: B-1206 Jingmao Guojigongyu 
S: 16 Baliqiao Nanjie, Beijing 101100

S: People's Repulic of China



N: Vlad Yasevich

E: vyasevich@gmail.com

D: SCTP protocol maintainer.



N: Aviad Yehezkel

E: aviadye@nvidia.com

D: Kernel TLS implementation and offload support.

Documentation/admin-guide/cgroup-v2.rst

+6 −9
Original line number Diff line number Diff line
@@ -1245,13 +1245,17 @@ PAGE_SIZE multiple when read back. 
	This is a simple interface to trigger memory reclaim in the

	target cgroup.



	This file accepts a string which contains the number of bytes to

	reclaim.

	This file accepts a single key, the number of bytes to reclaim.

	No nested keys are currently supported.



	Example::



	  echo "1G" > memory.reclaim



	The interface can be later extended with nested keys to

	configure the reclaim behavior. For example, specify the

	type of memory to reclaim from (anon, file, ..).



	Please note that the kernel can over or under reclaim from

	the target cgroup. If less bytes are reclaimed than the

	specified amount, -EAGAIN is returned.
@@ -1263,13 +1267,6 @@ PAGE_SIZE multiple when read back. 
	This means that the networking layer will not adapt based on

	reclaim induced by memory.reclaim.



	This file also allows the user to specify the nodes to reclaim from,

	via the 'nodes=' key, for example::



	  echo "1G nodes=0,1" > memory.reclaim



	The above instructs the kernel to reclaim memory from nodes 0,1.



  memory.peak

	A read-only single value file which exists on non-root

	cgroups.

Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst

0 → 100644
+91 −0
Original line number Diff line number Diff line 


.. SPDX-License-Identifier: GPL-2.0



Cross-Thread Return Address Predictions

=======================================



Certain AMD and Hygon processors are subject to a cross-thread return address

predictions vulnerability. When running in SMT mode and one sibling thread

transitions out of C0 state, the other sibling thread could use return target

predictions from the sibling thread that transitioned out of C0.



The Spectre v2 mitigations protect the Linux kernel, as it fills the return

address prediction entries with safe targets when context switching to the idle

thread. However, KVM does allow a VMM to prevent exiting guest mode when

transitioning out of C0. This could result in a guest-controlled return target

being consumed by the sibling thread.



Affected processors

-------------------



The following CPUs are vulnerable:



    - AMD Family 17h processors

    - Hygon Family 18h processors



Related CVEs

------------



The following CVE entry is related to this issue:



   ==============  =======================================

   CVE-2022-27672  Cross-Thread Return Address Predictions

   ==============  =======================================



Problem

-------



Affected SMT-capable processors support 1T and 2T modes of execution when SMT

is enabled. In 2T mode, both threads in a core are executing code. For the

processor core to enter 1T mode, it is required that one of the threads

requests to transition out of the C0 state. This can be communicated with the

HLT instruction or with an MWAIT instruction that requests non-C0.

When the thread re-enters the C0 state, the processor transitions back

to 2T mode, assuming the other thread is also still in C0 state.



In affected processors, the return address predictor (RAP) is partitioned

depending on the SMT mode. For instance, in 2T mode each thread uses a private

16-entry RAP, but in 1T mode, the active thread uses a 32-entry RAP. Upon

transition between 1T/2T mode, the RAP contents are not modified but the RAP

pointers (which control the next return target to use for predictions) may

change. This behavior may result in return targets from one SMT thread being

used by RET predictions in the sibling thread following a 1T/2T switch. In

particular, a RET instruction executed immediately after a transition to 1T may

use a return target from the thread that just became idle. In theory, this

could lead to information disclosure if the return targets used do not come

from trustworthy code.



Attack scenarios

----------------



An attack can be mounted on affected processors by performing a series of CALL

instructions with targeted return locations and then transitioning out of C0

state.



Mitigation mechanism

--------------------



Before entering idle state, the kernel context switches to the idle thread. The

context switch fills the RAP entries (referred to as the RSB in Linux) with safe

targets by performing a sequence of CALL instructions.



Prevent a guest VM from directly putting the processor into an idle state by

intercepting HLT and MWAIT instructions.



Both mitigations are required to fully address this issue.



Mitigation control on the kernel command line

---------------------------------------------



Use existing Spectre v2 mitigations that will fill the RSB on context switch.



Mitigation control for KVM - module parameter

---------------------------------------------



By default, the KVM hypervisor mitigates this issue by intercepting guest

attempts to transition out of C0. A VMM can use the KVM_CAP_X86_DISABLE_EXITS

capability to override those interceptions, but since this is not common, the

mitigation that covers this path is not enabled by default.



The mitigation for the KVM_CAP_X86_DISABLE_EXITS capability can be turned on

using the boolean module parameter mitigate_smt_rsb, e.g. ``kvm.mitigate_smt_rsb=1``.

Documentation/admin-guide/hw-vuln/index.rst

+1 −0
Original line number Diff line number Diff line
@@ -18,3 +18,4 @@ are configurable at compile, boot or run time. 
   core-scheduling.rst

   l1d_flush.rst

   processor_mmio_stale_data.rst

   cross-thread-rsb.rst