[PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0

[Will Deacon]

Hi Marc,

On Wed, Nov 22, 2017 at 04:52:36PM +0000, Marc Zyngier wrote:
> 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 at arm.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?

Good question. I think having a command-line option for this makes sense,
but I'd expect distributions to run with the config option enabled. That
basically leaves us with two changes we could make by forcing the option
to be enabled:

  1. The changes in the linker script could be made unconditional
  2. We could drop support for global mappings altogether

I'd be in favour of that because it avoids some conceptual complexity and
would allow us to rely on nG mappings in the future (there might be
something fun we can do with the percpu area, but there are dragons here).

I'd be interested in other people's opinions on this one.

Will