linux-stable.git/arch/arm/include, branch linux-5.17.y

irqchip/gic-v3: Refactor ISB + EOIR at ack time

2022-06-09T08:25:53+00:00

[ Upstream commit 6efb50923771f392122f5ce69dfc43b08f16e449 ]

There are cases where a context synchronization event is necessary
between an IRQ being raised and being handled, and there are races such
that we cannot rely upon the exception entry being subsequent to the
interrupt being raised. To fix this, we place an ISB between a read of
IAR and the subsequent invocation of an IRQ handler.

When EOI mode 1 is in use, we need to EOI an interrupt prior to invoking
its handler, and we have a write to EOIR for this. As this write to EOIR
requires an ISB, and this is provided by the gic_write_eoir() helper, we
omit the usual ISB in this case, with the logic being:

|	if (static_branch_likely(&supports_deactivate_key))
|		gic_write_eoir(irqnr);
|	else
|		isb();

This is somewhat opaque, and it would be a little clearer if there were
an unconditional ISB, with only the write to EOIR being conditional,
e.g.

|	if (static_branch_likely(&supports_deactivate_key))
|		write_gicreg(irqnr, ICC_EOIR1_EL1);
|
|	isb();

This patch rewrites the code that way, with this logic factored into a
new helper function with comments explaining what the ISB is for, as
were originally laid out in commit:

  39a06b67c2c1256b ("irqchip/gic: Ensure we have an ISB between ack and ->handle_irq")

Note that since then, we removed the IAR polling in commit:

  342677d70ab92142 ("irqchip/gic-v3: Remove acknowledge loop")

... which removed one of the two race conditions.

For consistency, other portions of the driver are made to manipulate
EOIR using write_gicreg() and explcit ISBs, and the gic_write_eoir()
helper function is removed.

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20220513133038.226182-3-mark.rutland@arm.com
Signed-off-by: Sasha Levin

arm: use fallback for random_get_entropy() instead of zero

2022-05-30T07:27:14+00:00

commit ff8a8f59c99f6a7c656387addc4d9f2247d75077 upstream.

In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies eventually. It's not as though
random_get_entropy_fallback() is super high precision or guaranteed to
be entropic, but basically anything that's not zero all the time is
better than returning zero all the time.

Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Reviewed-by: Russell King (Oracle) 
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Greg Kroah-Hartman

arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map

2022-05-18T08:28:22+00:00

commit 260364d112bc822005224667c0c9b1b17a53eafd upstream.

The semantics of pfn_valid() is to check presence of the memory map for a
PFN and not whether a PFN is covered by the linear map.  The memory map
may be present for NOMAP memory regions, but they won't be mapped in the
linear mapping.  Accessing such regions via __va() when they are
memremap()'ed will cause a crash.

On v5.4.y the crash happens on qemu-arm with UEFI [1]:

<1>[    0.084476] 8<--- cut here ---
<1>[    0.084595] Unable to handle kernel paging request at virtual address dfb76000
<1>[    0.084938] pgd = (ptrval)
<1>[    0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000

...

<4>[    0.093923] [] (memcpy) from [] (dmi_setup+0x60/0x418)
<4>[    0.094204] [] (dmi_setup) from [] (arm_dmi_init+0x8/0x10)
<4>[    0.094408] [] (arm_dmi_init) from [] (do_one_initcall+0x50/0x228)
<4>[    0.094619] [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1f8)
<4>[    0.094841] [] (kernel_init_freeable) from [] (kernel_init+0x8/0x10c)
<4>[    0.095057] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)

On kernels v5.10.y and newer the same crash won't reproduce on ARM because
commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()") changed the way memory regions are registered in
the resource tree, but that merely covers up the problem.

On ARM64 memory resources registered in yet another way and there the
issue of wrong usage of pfn_valid() to ensure availability of the linear
map is also covered.

Implement arch_memremap_can_ram_remap() on ARM and ARM64 to prevent access
to NOMAP regions via the linear mapping in memremap().

Link: https://lore.kernel.org/all/Yl65zxGgFzF1Okac@sirena.org.uk
Link: https://lkml.kernel.org/r/20220426060107.7618-1-rppt@kernel.org
Signed-off-by: Mike Rapoport 
Reported-by: "kernelci.org bot" 
Tested-by: Mark Brown 
Reviewed-by: Ard Biesheuvel 
Acked-by: Catalin Marinas 
Cc: Greg Kroah-Hartman 
Cc: Mark Brown 
Cc: Mark-PK Tsai 
Cc: Russell King 
Cc: Tony Lindgren 
Cc: Will Deacon 
Cc: 	[5.4+]
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

ARM: Spectre-BHB: provide empty stub for non-config

2022-03-11T20:42:49+00:00

When CONFIG_GENERIC_CPU_VULNERABILITIES is not set, references
to spectre_v2_update_state() cause a build error, so provide an
empty stub for that function when the Kconfig option is not set.

Fixes this build error:

  arm-linux-gnueabi-ld: arch/arm/mm/proc-v7-bugs.o: in function `cpu_v7_bugs_init':
  proc-v7-bugs.c:(.text+0x52): undefined reference to `spectre_v2_update_state'
  arm-linux-gnueabi-ld: proc-v7-bugs.c:(.text+0x82): undefined reference to `spectre_v2_update_state'

Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: linux-arm-kernel@lists.infradead.org
Cc: patches@armlinux.org.uk
Acked-by: Russell King (Oracle) 
Signed-off-by: Linus Torvalds

ARM: Do not use NOCROSSREFS directive with ld.lld

2022-03-09T22:14:16+00:00

ld.lld does not support the NOCROSSREFS directive at the moment, which
breaks the build after commit b9baf5c8c5c3 ("ARM: Spectre-BHB
workaround"):

  ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOCROSSREFS

Support for this directive will eventually be implemented, at which
point a version check can be added. To avoid breaking the build in the
meantime, just define NOCROSSREFS to nothing when using ld.lld, with a
link to the issue for tracking.

Cc: stable@vger.kernel.org
Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Link: https://github.com/ClangBuiltLinux/linux/issues/1609
Signed-off-by: Nathan Chancellor 
Signed-off-by: Linus Torvalds

ARM: fix co-processor register typo

2022-03-09T20:23:28+00:00

In the recent Spectre BHB patches, there was a typo that is only
exposed in certain configurations: mcr p15,0,XX,c7,r5,4 should have
been mcr p15,0,XX,c7,c5,4

Reported-by: kernel test robot 
Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Signed-off-by: Russell King (Oracle) 
Acked-by: Catalin Marinas 
Signed-off-by: Linus Torvalds

Merge tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm

2022-03-08T17:08:06+00:00

Pull ARM spectre fixes from Russell King:
 "ARM Spectre BHB mitigations.

  These patches add Spectre BHB migitations for the following Arm CPUs
  to the 32-bit ARM kernels:
   - Cortex A15
   - Cortex A57
   - Cortex A72
   - Cortex A73
   - Cortex A75
   - Brahma B15
  for CVE-2022-23960"

* tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: include unprivileged BPF status in Spectre V2 reporting
  ARM: Spectre-BHB workaround
  ARM: use LOADADDR() to get load address of sections
  ARM: early traps initialisation
  ARM: report Spectre v2 status through sysfs

ARM: Spectre-BHB workaround

2022-03-05T10:42:07+00:00

Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57,
Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as
well to be safe, which is affected by Spectre V2 in the same ways as
Cortex-A15.

Reviewed-by: Catalin Marinas 
Signed-off-by: Russell King (Oracle)

ARM: use LOADADDR() to get load address of sections

2022-03-05T10:41:58+00:00

Use the linker's LOADADDR() macro to get the load address of the
sections, and provide a macro to set the start and end symbols.

Acked-by: Catalin Marinas 
Signed-off-by: Russell King (Oracle)

ARM: report Spectre v2 status through sysfs

2022-03-05T10:41:22+00:00

As per other architectures, add support for reporting the Spectre
vulnerability status via sysfs CPU.

Acked-by: Catalin Marinas 
Signed-off-by: Russell King (Oracle)