user/sven/linux.git/Documentation, branch v5.9.11

xtensa: fix TLBTEMP area placement

2020-11-24T12:39:12Z

commit 481535c5b41d191b22775a6873de5ec0e1cdced1 upstream. fast_second_level_miss handler for the TLBTEMP area has an assumption that page table directory entry for the TLBTEMP address range is 0. For it to be true the TLBTEMP area must be aligned to 4MB boundary and not share its 4MB region with anything that may use a page table. This is not true currently: TLBTEMP shares space with vmalloc space which results in the following kinds of runtime errors when fast_second_level_miss loads page table directory entry for the vmalloc space instead of fixing up the TLBTEMP area: Unable to handle kernel paging request at virtual address c7ff0e00 pc = d0009275, ra = 90009478 Oops: sig: 9 [#1] PREEMPT CPU: 1 PID: 61 Comm: kworker/u9:2 Not tainted 5.10.0-rc3-next-20201110-00007-g1fe4962fa983-dirty #58 Workqueue: xprtiod xs_stream_data_receive_workfn a00: 90009478 d11e1dc0 c7ff0e00 00000020 c7ff0000 00000001 7f8b8107 00000000 a08: 900c5992 d11e1d90 d0cc88b8 5506e97c 00000000 5506e97c d06c8074 d11e1d90 pc: d0009275, ps: 00060310, depc: 00000014, excvaddr: c7ff0e00 lbeg: d0009275, lend: d0009287 lcount: 00000003, sar: 00000010 Call Trace: xs_stream_data_receive_workfn+0x43c/0x770 process_one_work+0x1a1/0x324 worker_thread+0x1cc/0x3c0 kthread+0x10d/0x124 ret_from_kernel_thread+0xc/0x18 Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman

powerpc/64s: flush L1D after user accesses

2020-11-22T09:15:32Z

commit 9a32a7e78bd0cd9a9b6332cbdc345ee5ffd0c5de upstream. 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 Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman

powerpc/64s: flush L1D on kernel entry

2020-11-22T09:15:32Z

commit f79643787e0a0762d2409b7b8334e83f22d85695 upstream. 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 Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman

can: j1939: swap addr and pgn in the send example

2020-11-18T18:22:05Z

[ Upstream commit ea780d39b1888ed5afc243c29b23d9bdb3828c7a ] The address was wrongly assigned to the PGN field and vice versa. Signed-off-by: Yegor Yefremov Link: https://lore.kernel.org/r/20201022083708.8755-1-yegorslists@googlemail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

bindings: soc: ti: soc: ringacc: remove ti,dma-ring-reset-quirk

2020-11-05T10:51:30Z

[ Upstream commit aee123f48f387ea62002cddb46c7cb04c96628df ] Remove "ti,dma-ring-reset-quirk" DT property as proper w/a handling is implemented now in Ringacc driver using SoC info. Signed-off-by: Grygorii Strashko Signed-off-by: Santosh Shilimkar Signed-off-by: Sasha Levin

media: videodev2.h: RGB BT2020 and HSV are always full range

2020-11-05T10:51:18Z

[ Upstream commit b305dfe2e93434b12d438434461b709641f62af4 ] The default RGB quantization range for BT.2020 is full range (just as for all the other RGB pixel encodings), not limited range. Update the V4L2_MAP_QUANTIZATION_DEFAULT macro and documentation accordingly. Also mention that HSV is always full range and cannot be limited range. When RGB BT2020 was introduced in V4L2 it was not clear whether it should be limited or full range, but full range is the right (and consistent) choice. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

xen/events: defer eoi in case of excessive number of events

2020-11-05T10:51:08Z

commit e99502f76271d6bc4e374fe368c50c67a1fd3070 upstream. In case rogue guests are sending events at high frequency it might happen that xen_evtchn_do_upcall() won't stop processing events in dom0. As this is done in irq handling a crash might be the result. In order to avoid that, delay further inter-domain events after some time in xen_evtchn_do_upcall() by forcing eoi processing into a worker on the same cpu, thus inhibiting new events coming in. The time after which eoi processing is to be delayed is configurable via a new module parameter "event_loop_timeout" which specifies the maximum event loop time in jiffies (default: 2, the value was chosen after some tests showing that a value of 2 was the lowest with an only slight drop of dom0 network throughput while multiple guests performed an event storm). How long eoi processing will be delayed can be specified via another parameter "event_eoi_delay" (again in jiffies, default 10, again the value was chosen after testing with different delay values). This is part of XSA-332. Cc: stable@vger.kernel.org Reported-by: Julien Grall Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini Reviewed-by: Wei Liu Signed-off-by: Greg Kroah-Hartman

dt-bindings: crypto: Specify that allwinner, sun8i-a33-crypto needs reset

2020-10-29T09:12:03Z

[ Upstream commit 884d1a334ae8130fabede56f59b224619ad6bca4 ] When adding allwinner,sun8i-a33-crypto, I forgot to add that it needs reset. Furthermore, there are no need to use items to list only one compatible in compatible list. Fixes: f81547ba7a98 ("dt-bindings: crypto: add new compatible for A33 SS") Signed-off-by: Corentin Labbe Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20200907175437.4464-1-clabbe.montjoie@gmail.com Signed-off-by: Sasha Levin

x86/fpu: Allow multiple bits in clearcpuid= parameter

2020-10-29T09:11:00Z

[ Upstream commit 0a4bb5e5507a585532cc413125b921c8546fc39f ] Commit 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument") changed clearcpuid parsing from __setup() to cmdline_find_option(). While the __setup() function would have been called for each clearcpuid= parameter on the command line, cmdline_find_option() will only return the last one, so the change effectively made it impossible to disable more than one bit. Allow a comma-separated list of bit numbers as the argument for clearcpuid to allow multiple bits to be disabled again. Log the bits being disabled for informational purposes. Also fix the check on the return value of cmdline_find_option(). It returns -1 when the option is not found, so testing as a boolean is incorrect. Fixes: 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument") Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200907213919.2423441-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin

netsec: ignore 'phy-mode' device property on ACPI systems

2020-10-29T09:10:55Z

[ Upstream commit acd7aaf51b20263a7e62d2a26569988c63bdd3d8 ] Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the Realtek PHY driver will override any TX/RX delay set by hardware straps if the phy-mode device property does not match. This is causing problems on SynQuacer based platforms (the only SoC that incorporates the netsec hardware), since many were built with this Realtek PHY, and shipped with firmware that defines the phy-mode as 'rgmii', even though the PHY is configured for TX and RX delay using pull-ups. >From the driver's perspective, we should not make any assumptions in the general case that the PHY hardware does not require any initial configuration. However, the situation is slightly different for ACPI boot, since it implies rich firmware with AML abstractions to handle hardware details that are not exposed to the OS. So in the ACPI case, it is reasonable to assume that the PHY comes up in the right mode, regardless of whether the mode is set by straps, by boot time firmware or by AML executed by the ACPI interpreter. So let's ignore the 'phy-mode' device property when probing the netsec driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA, which should work with any PHY provided that it is configured by the time the driver attaches to it. While at it, document that omitting the mode is permitted for DT probing as well, by setting the phy-mode DT property to the empty string. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel Reviewed-by: Ilias Apalodimas Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman