Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE

From: Kees Cook <keescook@chromium.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Jeffrey Vander Stoep <jeffv@google.com>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Olof Johansson <olof@lixom.net>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Arnd Bergmann <arnd@arndb.de>, Shawn Guo <shawnguo@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE
Date: Fri, 21 Jun 2019 13:54:10 -0700	[thread overview]
Message-ID: <CAGXu5j+aihyZWUUTTxweXxEMfgL12HULqNhHj_mUedLefFrcLA@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOdmQ+WdD8nvLz_VB_5atDi56fv485Xsn+mHJZKnyj6L-JA@mail.gmail.com>

On Fri, Jun 21, 2019 at 1:28 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Thu, Jun 20, 2019 at 1:17 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> > I think it is mostly controversial among non-security folks, who think
> > that every mitigation by itself should be bullet proof. Security folks
> > tend to think more about how each layer reduces the attack surface,
> > hopefully resulting in a secure system when all layers are enabled.
>
> + Kees, Sami, Jeff
> It's a relatively low cost part of our defense in depth strategy.
> Maybe (Kees, Sami, Jeff) have more thoughts?

Right -- the thought is that it provides more benefit than
complication. It is hardly a perfect defense, but it does provide
building blocks to more interesting situations. For example, once
execute-only memory is more common, KASLR + XOM means there is a not
insignificant defense against automated ROP. And KASLR is a general
precursor to fine-grained KASLR (i.e. randomizing on function).

> > So KASLR is known to be broken unless you enable KPTI as well, so that
> > is something we could take into account. I.e., mitigations that don't
> > reduce the attack surface at all are just pointless complexity, which
> > should obviously be avoided.
>
> (Note to Sami + Jeff if they had KPTI on their radar)

I prefer that KPTI always stay enabled. :)

> > Another thing to note is that the runtime cost of KASLR is ~zero, with
> > the exception of the module PLTs. However, the latter could do with
> > some additional coverage as well, so in summary, I think enabling this
> > is a good thing. Otherwise, we could disable full module randomization
> > so that the module PLT code doesn't get used in practice.
> >
> > Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook