linux-toradex.git/arch/arm/kernel, branch v4.4.153

ARM: 8748/1: mm: Define vdso_start, vdso_end as array

2018-05-30T05:49:06+00:00

[ Upstream commit 73b9160d0dfe44dfdaffd6465dc1224c38a4a73c ]

Define vdso_start, vdso_end as array to avoid compile-time analysis error
for the case of built with CONFIG_FORTIFY_SOURCE.

and, since vdso_start, vdso_end are used in vdso.c only,
move extern-declaration from vdso.h to vdso.c.

If kernel is built with CONFIG_FORTIFY_SOURCE,
compile-time error happens at this code.
- if (memcmp(&vdso_start, "177ELF", 4))

The size of "&vdso_start" is recognized as 1 byte, but n is 4,
So that compile-time error is reported.

Acked-by: Kees Cook 
Signed-off-by: Jinbum Park 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: 8771/1: kprobes: Prohibit kprobes on do_undefinstr

2018-05-26T06:48:56+00:00

commit eb0146daefdde65665b7f076fbff7b49dade95b9 upstream.

Prohibit kprobes on do_undefinstr because kprobes on
arm is implemented by undefined instruction. This means
if we probe do_undefinstr(), it can cause infinit
recursive exception.

Fixes: 24ba613c9d6c ("ARM kprobes: core code")
Signed-off-by: Masami Hiramatsu 
Cc: stable@vger.kernel.org
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER

2018-03-24T09:58:41+00:00

[ Upstream commit 6f05d0761af612e04572ba4d65b4c0274a88444f ]

The support for dynamic ftrace with CONFIG_DEBUG_RODATA involves
overriding the weak arch_ftrace_update_code() with a variant which makes
the kernel text writable around the patching.

This override was however added under the CONFIG_OLD_MCOUNT ifdef, and
CONFIG_OLD_MCOUNT is only enabled if frame pointers are enabled.

This leads to non-functional dynamic ftrace (ftrace triggers a
WARN_ON()) when CONFIG_DEBUG_RODATA is enabled and CONFIG_FRAME_POINTER
is not.

Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE
ifdef where it belongs.

Fixes: 80d6b0c2eed2a ("ARM: mm: allow text and rodata sections to be read-only")
Suggested-by: Nicolai Stange 
Suggested-by: Rabin Vincent 
Signed-off-by: Abel Vesa 
Acked-by: Rabin Vincent 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: avoid faulting on qemu

2017-12-16T09:33:50+00:00

commit 3aaf33bebda8d4ffcc0fc8ef39e6c1ac68823b11 upstream.

When qemu starts a kernel in a bare environment, the default SCR has
the AW and FW bits clear, which means that the kernel can't modify
the PSR A or PSR F bits, and means that FIQs and imprecise aborts are
always masked.

When running uboot under qemu, the AW and FW SCR bits are set, and the
kernel functions normally - and this is how real hardware behaves.

Fix this for qemu by ignoring the FIQ bit.

Fixes: 8bafae202c82 ("ARM: BUG if jumping to usermode address in kernel mode")
Signed-off-by: Russell King 
Cc: Alex Shi 
Signed-off-by: Greg Kroah-Hartman

ARM: BUG if jumping to usermode address in kernel mode

2017-12-16T09:33:50+00:00

commit 8bafae202c82dc257f649ea3c275a0f35ee15113 upstream.

Detect if we are returning to usermode via the normal kernel exit paths
but the saved PSR value indicates that we are in kernel mode.  This
could occur due to corrupted stack state, which has been observed with
"ftracetest".

This ensures that we catch the problem case before we get to user code.

Signed-off-by: Russell King 
Cc: Alex Shi 
Signed-off-by: Greg Kroah-Hartman

ARM: 8720/1: ensure dump_instr() checks addr_limit

2017-11-15T16:13:12+00:00

commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.

When CONFIG_DEBUG_USER is enabled, it's possible for a user to
deliberately trigger dump_instr() with a chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

So that we can use the same code to dump user instructions and kernel
instructions, the common dumping code is factored out to __dump_instr(),
with the fs manipulated appropriately in dump_instr() around calls to
this.

Signed-off-by: Mark Rutland 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8452/3: PJ4: make coprocessor access sequences buildable in Thumb2 mode

2017-05-14T11:32:54+00:00

commit 5008efc83bf85b647aa1cbc44718b1675bbb7444 upstream.

The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2
mode, due to the way it performs arithmetic on the program counter, so it
is built in ARM mode instead. However, building C files in ARM mode under
CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed
by subsystems like ftrace does not expect having to deal with interworking
branches.

Since the sequence in question is simply a poor man's ISB instruction,
let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2
implies V7, so 'isb' should always be supported in that case.

Acked-by: Arnd Bergmann 
Acked-by: Nicolas Pitre 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write

2017-02-14T23:22:51+00:00

commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Fixes: 5be6f62b0059 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
Signed-off-by: Dave Martin 
Acked-by: Russell King 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8613/1: Fix the uaccess crash on PB11MPCore

2017-01-26T07:23:49+00:00

commit 90f92c631b210c1e97080b53a9d863783281a932 upstream.

The following patch was sketched by Russell in response to my
crashes on the PB11MPCore after the patch for software-based
priviledged no access support for ARMv8.1. See this thread:
http://marc.info/?l=linux-arm-kernel&m=144051749807214&w=2

I am unsure what is going on, I suspect everyone involved in
the discussion is. I just want to repost this to get the
discussion restarted, as I still have to apply this patch
with every kernel iteration to get my PB11MPCore Realview
running.

Testing by Neil Armstrong on the Oxnas NAS has revealed that
this bug exist also on that widely deployed hardware, so
we are probably currently regressing all ARM11MPCore systems.

Cc: Russell King 
Cc: Will Deacon 
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Tested-by: Neil Armstrong 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs

2017-01-26T07:23:49+00:00

commit ddc37832a1349f474c4532de381498020ed71d31 upstream.

On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
undefined instruction trap within write_wb_reg. This is because Scorpion
CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
watchpoint registers are treated as undefined.

It's possible to trigger similar crashes later on from userspace, by
requesting the kernel to install a breakpoint or watchpoint, as we can
go idle at any point between the reset of the debug registers and their
later use. This has always been the case.

Given that this has always been broken, no-one has complained until now,
and there is no clear workaround, disable hardware breakpoints and
watchpoints on Scorpion to avoid these issues.

Signed-off-by: Mark Rutland 
Reported-by: Linus Walleij 
Reviewed-by: Stephen Boyd 
Acked-by: Will Deacon 
Cc: Russell King 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman