]> git.karo-electronics.de Git - linux-beck.git/commit
arm64: mm: fix location of _etext
authorArd Biesheuvel <ard.biesheuvel@linaro.org>
Thu, 23 Jun 2016 13:53:17 +0000 (15:53 +0200)
committerCatalin Marinas <catalin.marinas@arm.com>
Mon, 27 Jun 2016 17:21:27 +0000 (18:21 +0100)
commit9fdc14c55cd6579d619ccd9d40982e0805e62b6d
tree39c75ed542eccac983b74f9297b2c562f06a6bd8
parentea2cbee3bc671390139802dd0d50b08db024b03c
arm64: mm: fix location of _etext

As Kees Cook notes in the ARM counterpart of this patch [0]:

  The _etext position is defined to be the end of the kernel text code,
  and should not include any part of the data segments. This interferes
  with things that might check memory ranges and expect executable code
  up to _etext.

In particular, Kees is referring to the HARDENED_USERCOPY patch set [1],
which rejects attempts to call copy_to_user() on kernel ranges containing
executable code, but does allow access to the .rodata segment. Regardless
of whether one may or may not agree with the distinction, it makes sense
for _etext to have the same meaning across architectures.

So let's put _etext where it belongs, between .text and .rodata, and fix
up existing references to use __init_begin instead, which unlike _end_rodata
includes the exception and notes sections as well.

The _etext references in kaslr.c are left untouched, since its references
to [_stext, _etext) are meant to capture potential jump instruction targets,
and so disregarding .rodata is actually an improvement here.

[0] http://article.gmane.org/gmane.linux.kernel/2245084
[1] http://thread.gmane.org/gmane.linux.kernel.hardened.devel/2502

Reported-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arch/arm64/kernel/setup.c
arch/arm64/kernel/vmlinux.lds.S
arch/arm64/mm/init.c
arch/arm64/mm/mmu.c