From: Will Deacon <will.deacon@arm.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: mark.rutland@arm.com,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Arnd Bergmann <arnd@arndb.de>,
ard.biesheuvel@linaro.org,
Maxime Ripard <maxime.ripard@bootlin.com>,
catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Dinh Nguyen <dinguyen@kernel.org>,
broonie@kernel.org, Jagan Teki <jagan@amarulasolutions.com>,
Olof Johansson <olof@lixom.net>, Shawn Guo <shawnguo@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE
Date: Thu, 20 Jun 2019 08:46:58 +0100 [thread overview]
Message-ID: <20190620074640.GA27228@brain-police> (raw)
In-Reply-To: <20190620003244.261595-1-ndesaulniers@google.com>
Hi Nick,
On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote:
> Generated via:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make menuconfig
> <enable CONFIG_RANDOMIZE_BASE aka KASLR>
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make savedefconfig
> $ mv defconfig arch/arm64/configs/defconfig
Hmm, I'm in two minds about whether we want this on by default. On the plus
side, it gets us extra testing coverage, although the /vast/ majority of
firmware implementations I run into either don't pass a seed or don't
provide a working EFI_RNG. Perhaps that's just a chicken-and-egg problem
which can be solved if we shout loud enough when we fail to randomize; we'll
also eventually be in a better position when CPUs start implementing the
v8.5 RNG instructions (but don't hold your breath unless you have an
unusually high lung capacity).
On the flip side, I worry that it could make debugging more difficult, but I
don't know whether that's a genuine concern or not. I'm assuming you've
debugged your fair share of crashes from KASLR-enabled kernels; how bad is
it? (I'm thinking of the case where somebody mails you part of a panic log
and a .config).
Irrespective of the above, I know Catalin was running into issues with his
automated tests where the kernel would die silently during early boot with
some seeds. That's a bit rubbish if it's still the case -- Catalin?
Finally, I know that (K)ASLR can be a bit controversial amongst security
folks, with some seeing it as purely a smoke-and-mirrors game with no
tangible benefits other than making us feel better about ourselves. Is it
still the case that it can be trivially bypassed, or do you see it actually
preventing some attacks in production?
Sorry for the barrage of questions, but I think enabling this one by default
is quite a significant thing to do and probably deserves a bit of scrutiny
beforehand.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-20 7:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-20 0:32 [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE Nick Desaulniers
2019-06-20 7:46 ` Will Deacon [this message]
2019-06-20 8:17 ` Ard Biesheuvel
2019-06-21 20:27 ` Nick Desaulniers
2019-06-21 20:54 ` Kees Cook
2019-06-24 9:57 ` Will Deacon
2019-06-24 10:06 ` Ard Biesheuvel
2019-06-25 15:39 ` Catalin Marinas
2019-06-25 15:42 ` Ard Biesheuvel
2019-06-25 16:03 ` Catalin Marinas
2019-06-25 16:24 ` Ard Biesheuvel
2019-06-24 17:58 ` [PATCH v2] arm64: defconfig: " Nick Desaulniers
2019-06-25 7:55 ` Catalin Marinas
2019-06-24 9:51 ` [PATCH] arm64: defconfig: update and " Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190620074640.GA27228@brain-police \
--to=will.deacon@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dinguyen@kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=jagan@amarulasolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@bootlin.com \
--cc=ndesaulniers@google.com \
--cc=olof@lixom.net \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).