lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f82c5329-6547-ccfb-9846-5a59fd471720@arm.com>
Date:   Wed, 22 Nov 2017 16:52:36 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Will Deacon <will.deacon@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org, catalin.marinas@....com,
        mark.rutland@....com, ard.biesheuvel@...aro.org,
        sboyd@...eaurora.org, dave.hansen@...ux.intel.com,
        keescook@...omium.org
Subject: Re: [PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0

Hi Will,

On 17/11/17 18:22, Will Deacon wrote:
> Add a Kconfig entry to control use of the entry trampoline, which allows
> us to unmap the kernel whilst running in userspace and improve the
> robustness of KASLR.
> 
> Signed-off-by: Will Deacon <will.deacon@....com>
> ---
>  arch/arm64/Kconfig | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f0fcbfc2262e..f99ffb88843a 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -796,6 +796,19 @@ config FORCE_MAX_ZONEORDER
>  	  However for 4K, we choose a higher default value, 11 as opposed to 10, giving us
>  	  4M allocations matching the default size used by generic code.
>  
> +config UNMAP_KERNEL_AT_EL0
> +	bool "Unmap kernel when running in userspace (aka \"KAISER\")"
> +	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.
> +
> +	  If unsure, say Y.
> +
>  menuconfig ARMV8_DEPRECATED
>  	bool "Emulate deprecated/obsolete ARMv8 instructions"
>  	depends on COMPAT
> 

Since this seems to be the recommended setting, I wonder if there is any
real value in keeping the old code around. My hunch is that the lack of
use in the field will make it fragile and that it will eventually bit-rot.

Do you have any plan to eventually drop the non-KAISER switch code?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ