system/linux
system/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux synced 2024-09-20 11:07:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry

Browse source 
Although CONFIG_UNMAP_KERNEL_AT_EL0 does make KASLR more robust, it's
actually more useful as a mitigation against speculation attacks that
can leak arbitrary kernel data to userspace through speculation.

Reword the Kconfig help message to reflect this, and make the option
depend on EXPERT so that it is on by default for the majority of users.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This commit is contained in:
Will Deacon 2017-11-14 16:19:39 +00:00 committed by Catalin Marinas
parent be04a6d112
commit 0617052ddd
1 changed files with 6 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
arch/arm64/Kconfig
View file

@ -863,15 +863,14 @@ config FORCE_MAX_ZONEORDER
4M allocations matching the default size used by generic code.
config UNMAP_KERNEL_AT_EL0
bool "Unmap kernel when running in userspace (aka \"KAISER\")"
bool "Unmap kernel when running in userspace (aka \"KAISER\")" if EXPERT
default y
help
Some attacks against KASLR make use of the timing difference between
a permission fault which could arise from a page table entry that is
present in the TLB, and a translation fault which always requires a
page table walk. This option defends against these attacks by unmapping
the kernel whilst running in userspace, therefore forcing translation
faults for all of kernel space.
Speculation attacks against some high-performance processors can
be used to bypass MMU permission checks and leak kernel data to
userspace. This can be defended against by unmapping the kernel
when running in userspace, mapping it back in on exception entry
via a trampoline page in the vector table.
If unsure, say Y.