Commit 1e8a3f0d authored by Jakub Kicinski's avatar Jakub Kicinski
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 

net/dsa/dsa2.c
  commit afb3cc1a ("net: dsa: unlock the rtnl_mutex when dsa_master_setup() fails")
  commit e83d5653 ("net: dsa: replay master state events in dsa_tree_{setup,teardown}_master")
https://lore.kernel.org/all/20220307101436.7ae87da0@canb.auug.org.au/

drivers/net/ethernet/intel/ice/ice.h
  commit 97b01291 ("ice: Fix error with handling of bonding MTU")
  commit 43113ff7 ("ice: add TTY for GNSS module for E810T device")
https://lore.kernel.org/all/20220310112843.3233bcf1@canb.auug.org.au/

drivers/staging/gdm724x/gdm_lte.c
  commit fc7f750d ("staging: gdm724x: fix use after free in gdm_lte_rx()")
  commit 4bcc4249 ("staging: Use netif_rx().")
https://lore.kernel.org/all/20220308111043.1018a59d@canb.auug.org.au/



Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
parents 3e18bcb7 186d32bb

.mailmap

+3 −0
Original line number Diff line number Diff line
@@ -187,6 +187,8 @@ Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com> 
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>

Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.cz>

Jiri Slaby <jirislaby@kernel.org> <xslaby@fi.muni.cz>

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 Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
@@ -216,6 +218,7 @@ Koushik <raghavendra.koushik@neterion.com> 
Krishna Manikandan <quic_mkrishn@quicinc.com> <mkrishn@codeaurora.org>

Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>

Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>

Krzysztof Kozlowski <krzk@kernel.org> <krzysztof.kozlowski@canonical.com>

Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Kuogee Hsieh <quic_khsieh@quicinc.com> <khsieh@codeaurora.org>

Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>

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

+33 −17
Original line number Diff line number Diff line
@@ -60,8 +60,8 @@ privileged data touched during the speculative execution. 
Spectre variant 1 attacks take advantage of speculative execution of

conditional branches, while Spectre variant 2 attacks use speculative

execution of indirect branches to leak privileged memory.

See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`

:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.

See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[6] <spec_ref6>`

:ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.



Spectre variant 1 (Bounds Check Bypass)

---------------------------------------
@@ -131,6 +131,19 @@ steer its indirect branch speculations to gadget code, and measure the 
speculative execution's side effects left in level 1 cache to infer the

victim's data.



Yet another variant 2 attack vector is for the attacker to poison the

Branch History Buffer (BHB) to speculatively steer an indirect branch

to a specific Branch Target Buffer (BTB) entry, even if the entry isn't

associated with the source address of the indirect branch. Specifically,

the BHB might be shared across privilege levels even in the presence of

Enhanced IBRS.



Currently the only known real-world BHB attack vector is via

unprivileged eBPF. Therefore, it's highly recommended to not enable

unprivileged eBPF, especially when eIBRS is used (without retpolines).

For a full mitigation against BHB attacks, it's recommended to use

retpolines (or eIBRS combined with retpolines).



Attack scenarios

----------------
@@ -364,13 +377,15 @@ The possible values in this file are: 


  - Kernel status:



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

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

  'Not affected'                            The processor is not vulnerable

  'Vulnerable'                          Vulnerable, no mitigation

  'Mitigation: Full generic retpoline'  Software-focused mitigation

  'Mitigation: Full AMD retpoline'      AMD-specific software mitigation

  'Mitigation: None'                        Vulnerable, no mitigation

  'Mitigation: Retpolines'                  Use Retpoline thunks

  'Mitigation: LFENCE'                      Use LFENCE instructions

  'Mitigation: Enhanced IBRS'               Hardware-focused mitigation

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

  'Mitigation: Enhanced IBRS + Retpolines'  Hardware-focused + Retpolines

  'Mitigation: Enhanced IBRS + LFENCE'      Hardware-focused + LFENCE

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



  - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is

    used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
@@ -583,12 +598,13 @@ kernel command line. 


		Specific mitigations can also be selected manually:



		retpoline

					replace indirect branches

		retpoline,generic

					google's original retpoline

		retpoline,amd

					AMD-specific minimal thunk

                retpoline               auto pick between generic,lfence

                retpoline,generic       Retpolines

                retpoline,lfence        LFENCE; indirect branch

                retpoline,amd           alias for retpoline,lfence

                eibrs                   enhanced IBRS

                eibrs,retpoline         enhanced IBRS + Retpolines

                eibrs,lfence            enhanced IBRS + LFENCE



		Not specifying this option is equivalent to

		spectre_v2=auto.
@@ -599,7 +615,7 @@ kernel command line. 
		spectre_v2=off. Spectre variant 1 mitigations

		cannot be disabled.



For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`.

For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt



Mitigation selection guide

--------------------------
@@ -681,7 +697,7 @@ AMD white papers: 


.. _spec_ref6:



[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.

[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.



ARM white papers:

Documentation/admin-guide/kernel-parameters.txt

+6 −2
Original line number Diff line number Diff line
@@ -5361,8 +5361,12 @@ 
			Specific mitigations can also be selected manually:



			retpoline	  - replace indirect branches

			retpoline,generic - google's original retpoline

			retpoline,amd     - AMD-specific minimal thunk

			retpoline,generic - Retpolines

			retpoline,lfence  - LFENCE; indirect branch

			retpoline,amd     - alias for retpoline,lfence

			eibrs		  - enhanced IBRS

			eibrs,retpoline   - enhanced IBRS + Retpolines

			eibrs,lfence      - enhanced IBRS + LFENCE



			Not specifying this option is equivalent to

			spectre_v2=auto.

Documentation/admin-guide/mm/pagemap.rst

+1 −1
Original line number Diff line number Diff line
@@ -23,7 +23,7 @@ There are four components to pagemap: 
    * Bit  56    page exclusively mapped (since 4.2)

    * Bit  57    pte is uffd-wp write-protected (since 5.13) (see

      :ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`)

    * Bits 57-60 zero

    * Bits 58-60 zero

    * Bit  61    page is file-page or shared-anon (since 3.5)

    * Bit  62    page swapped

    * Bit  63    page present

Documentation/core-api/dma-attributes.rst

+0 −8
Original line number Diff line number Diff line
@@ -130,11 +130,3 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged 
subsystem that the buffer is fully accessible at the elevated privilege

level (and ideally inaccessible or at least read-only at the

lesser-privileged levels).
 


DMA_ATTR_OVERWRITE

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



This is a hint to the DMA-mapping subsystem that the device is expected to

overwrite the entire mapped size, thus the caller does not require any of the

previous buffer contents to be preserved. This allows bounce-buffering

implementations to optimise DMA_FROM_DEVICE transfers.