summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorArd Biesheuvel <ard.biesheuvel@linaro.org>2016-06-23 15:53:17 +0200
committerSami Tolvanen <samitolvanen@google.com>2016-09-06 15:52:14 +0000
commit79389c0d786133e83dc1ecc991767837cf713b83 (patch)
tree3b96e0bdf1cbde196c3fb1b492ff6ca59ab1465c /include/linux
parentfed752db02277e34e92262daac24ad4216e79c56 (diff)
BACKPORT: 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> Change-Id: I8f6582525217b9ca324f6a382ea52d30ce1d0dbd (cherry picked from commit 9fdc14c55cd6579d619ccd9d40982e0805e62b6d) Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions