Skip to content
GitLab
Switch branch/tag
  1. 04 Feb, 2020 5 commits
  3. 27 Jan, 2020 6 commits
  5. 25 Jan, 2020 8 commits
    • Vladimir Murzin's avatar
      ARM: 8954/1: NOMMU: remove stubs for swapops · 03a575a6
      Vladimir Murzin authored 
      Stubs for swapops are not required after 9b98fa22

 (mm: stub out
all of swapops.h for !CONFIG_MMU)
Signed-off-by: Vladimir Murzin's avatarVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      03a575a6
    • Vincenzo Frascino's avatar
      ARM: 8952/1: Disable kmemleak on XIP kernels · bc420c6c
      Vincenzo Frascino authored 
      

Kmemleak relies on specific symbols to register the read only data
during init (e.g. __start_ro_after_init).
Trying to build an XIP kernel on arm results in the linking error
reported below because when this option is selected read only data
after init are not allowed since .data is read only (.rodata).

  arm-linux-gnueabihf-ld: mm/kmemleak.o: in function `kmemleak_init':
  kmemleak.c:(.init.text+0x148): undefined reference to `__end_ro_after_init'
  arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x14c):
     undefined reference to `__end_ro_after_init'
  arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x150):
     undefined reference to `__start_ro_after_init'
  arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x156):
     undefined reference to `__start_ro_after_init'
  arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x162):
     undefined reference to `__start_ro_after_init'
  arm-linux-gnueabihf-ld: kmemleak.c:(.init.text+0x16a):
     undefined reference to `__start_ro_after_init'
  linux/Makefile:1078: recipe for target 'vmlinux' failed

Fix the issue enabling kmemleak only on non XIP kernels.
Signed-off-by: Vincenzo Frascino's avatarVincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      bc420c6c
    • Vincenzo Frascino's avatar
      ARM: 8951/1: Fix Kexec compilation issue. · 76950f71
      Vincenzo Frascino authored 
      

To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to
find a memblock in a range.
SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in
these conditions results in a build error:

  linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’:
  linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared
     (first use in this function); did you mean ‘SECTIONS_WIDTH’?
             crash_size, SECTION_SIZE);
                         ^~~~~~~~~~~~
                         SECTIONS_WIDTH
  linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier
     is reported only once for each function it appears in
  linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o'
     failed

Make KEXEC depend on MMU to fix the compilation issue.
Signed-off-by: Vincenzo Frascino's avatarVincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      76950f71
    • Olof Johansson's avatar
      ARM: 8949/1: mm: mark free_memmap as __init · 31f3010e
      Olof Johansson authored 
      As of commit ac7c3e4f ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly"), free_memmap() might not always be inlined, and thus is
triggering a section warning:

WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free()

Mark it as __init, since the faller (free_unused_memmap) already is.

Fixes: ac7c3e4f

 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly")
Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      31f3010e
    • Vincent Whitchurch's avatar
      ARM: 8948/1: Prevent OOB access in stacktrace · 40ff1ddb
      Vincent Whitchurch authored 
      

The stacktrace code can read beyond the stack size, when it attempts to
read pt_regs from exception frames.

This can happen on normal, non-corrupt stacks.  Since the unwind
information in the extable is not correct for function prologues, the
unwinding code can return data from the stack which is not actually the
caller function address, and if in_entry_text() happens to succeed on
this value, we can end up reading data from outside the task's stack
when attempting to read pt_regs, since there is no bounds check.

Example:

 [<8010e729>] (unwind_backtrace) from [<8010a9c9>] (show_stack+0x11/0x14)
 [<8010a9c9>] (show_stack) from [<8057d8d7>] (dump_stack+0x87/0xac)
 [<8057d8d7>] (dump_stack) from [<8012271d>] (tasklet_action_common.constprop.4+0xa5/0xa8)
 [<8012271d>] (tasklet_action_common.constprop.4) from [<80102333>] (__do_softirq+0x11b/0x31c)
 [<80102333>] (__do_softirq) from [<80122485>] (irq_exit+0xad/0xd8)
 [<80122485>] (irq_exit) from [<8015f3d7>] (__handle_domain_irq+0x47/0x84)
 [<8015f3d7>] (__handle_domain_irq) from [<8036a523>] (gic_handle_irq+0x43/0x78)
 [<8036a523>] (gic_handle_irq) from [<80101a49>] (__irq_svc+0x69/0xb4)
 Exception stack(0xeb491f58 to 0xeb491fa0)
 1f40:                                                       7eb14794 00000000
 1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000
 1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff
 [<80101a49>] (__irq_svc) from [<8023d09c>] (do_pipe2+0x0/0xac)
 [<8023d09c>] (do_pipe2) from [<ffffffff>] (0xffffffff)
 Exception stack(0xeb491fc8 to 0xeb492010)
 1fc0:                   008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c
 1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000
 2000: 00000001 00000000 ea846c00 ea847cc0

In this example, the stack limit is 0xeb492000, but 16 bytes outside the
stack have been read.

Fix it by adding bounds checks.
Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      40ff1ddb
    • Masahiro Yamada's avatar
      ARM: 8945/1: decompressor: use CONFIG option instead of cc-option · 9db78852
      Masahiro Yamada authored 
      

The Kconfig stage (arch/Kconfig) has already evaluated whether the
compiler supports -fno-stack-protector.

You can use CONFIG_CC_HAS_STACKPROTECTOR_NONE instead of invoking
the compiler to check the flag here.
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      9db78852
    • Ard Biesheuvel's avatar
      ARM: 8942/1: Revert "8857/1: efi: enable CP15 DMB instructions before cleaning the cache" · cf17a1e3
      Ard Biesheuvel authored 
      This reverts commit e17b1af9

, which is
no longer necessary now that the v7 specific routines take care not to
issue CP15 barrier instructions before they are enabled in SCTLR.
Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      cf17a1e3
    • Ard Biesheuvel's avatar
      ARM: 8941/1: decompressor: enable CP15 barrier instructions in v7 cache setup code · 8239fc77
      Ard Biesheuvel authored 
      Commit e17b1af9



  "ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache"

added some explicit handling of the CP15BEN bit in the SCTLR system
register, to ensure that CP15 barrier instructions are enabled, even
if we enter the decompressor via the EFI stub.

However, as it turns out, there are other ways in which we may end up
using CP15 barrier instructions without them being enabled. I.e., when
the decompressor startup code skips the cache_on() initially, we end
up calling cache_clean_flush() with the caches and MMU off, in which
case the CP15BEN bit in SCTLR may not be programmed either. And in
fact, cache_on() itself issues CP15 barrier instructions before actually
enabling them by programming the new SCTLR value (and issuing an ISB)

Since these routines are shared between v7 CPUs and older ones that
implement the CPUID extension as well, using the ordinary v7 barrier
instructions in this code is not possible, and so we should enable the
CP15 ones explicitly before issuing them. Note that a v7 ISB is still
required between programming the SCTLR register and using the CP15 barrier
instructions, and we should take care to branch over it if the CP15BEN
bit is already set, given that in that case, the CPU may not support it.
Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      8239fc77
  7. 23 Jan, 2020 21 commits